cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <Giacomo.P...@pwr.ch>
Subject Re: [Cocoon2] XSP 2.0 changes list
Date Mon, 22 May 2000 17:47:59 GMT

Stefano Mazzocchi schrieb:
> 
> 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.

All +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.

+1

> 
> 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.

Excellent!

> 
> 5) Encoding attribute in <xsp:page>
> 
> This to allow XSP to generate a declared encoding.
> 
> 6) Taglib creation kit
> 
> This to simplify the creation of taglibs.

Do you include "suggestions and guide lines on how to desing and evolve
a custom taglib"?

Giacomo

-- 
PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7                     Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen                    Web:   http://www.pwr.ch

Mime
View raw message