cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject Re: [Cocoon2] XSP 2.0 changes list
Date Mon, 22 May 2000 17:58:25 GMT
On Mon, 22 May 2000, Stefano Mazzocchi wrote:

> XSP is one of the best thing that Cocoon introduced, but experience over
> the last months showed there are problems and things that can be tuned.
> Here follows a list of things that Ricardo and I would like to
> change/improve.
> 
> 1) Doctype ---------------------
> 
> The indicated namespace for XSP 1.0 was
> 
>    "http://www.apache.org/1999/XSP/Core"
> 
> we would like to propose this new URI schema instead
> 
>  "http://xml.apache.org/cocoon/XSP/2.0"
> 
> for the core namespace, then, for taglibs, 
> 
>  "http://xml.apache.org/cocoon/XSP/util/1.0"
> 
> where "util" is the taglib name and "1.0" its version.
> 
> This allows better visibility of the URI and better control since we
> maintain directly the http://xml.apache.org/cocoon/ URI space. Also is
> easier to understand and doesn't follow the stupid W3C idea of
> year-based URIs cataloging which is just useless and dangerous in the
> long run.

Big ol' honking +1.

> 2) Deprecation of <xsp:content>
> 
> Implementations show that xsp:content is not useful to XSP semantics.
> Since very element that doesn't belong to the XSP controlled namespaces,
> will be automatically interpreted as content.

+0

> 3) Optional use of <xsp:page> for pure-taglib usage.
> 
> This would allow a page like
> 
>  <whatever>
>    Today is <util:date/>
>  </whatever>
> 
> to be processable by the XSP engine without requiring to wrap everything
> by <xsp:page>. This will also remove the problem with having to define
> one and only one content element after <xsp:page>. This is mostly useful
> for taglib usage.

+1

> 4) Namespace-driven taglib evaluation
> 
> You should not need to use <xsp:logicsheet> (as currently implemented in
> Cocoon 1.x) to turn on taglib processing, but it should be automatic,
> given the XSP engine with configurations that associate the specific
> logicsheet to the registered namespace.
> 
> So, something like this
> 
>  <?xml version="1.0"?>
>  <whatever xmlns:util="http://xml.apache.org/cocoon/XSP/util/1.2">
>   Today is <util:date/>
>  </whatever>
> 
> will be processed by the XSP engine by using the logicsheet registered
> to the namespace in the engine configurations. This improves the current
> model because:
> 
> - URIs are absolute locations and associate the "meaning" of the taglib,
> leaving to the engine configuration the ability to map these namespaces
> to the right logicsheet.
> 
> - better crossplatform since XSP doesn't rule _how_ the XSP engine
> should evaluate those tags or how their content is created.
> 
> - better language abstraction since from the point above, every XSP
> engine is free to use run-time interpretation or page compilation or
> document fragment caching and so forth.

+1

> 5) Encoding attribute in <xsp:page>
> 
> This to allow XSP to generate a declared encoding.

+0

> 6) Taglib creation kit
> 
> This to simplify the creation of taglibs.

ha! would love to see it, but i don't see it happening.

- donald


Mime
View raw message