cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject [Cocoon2] XSP 2.0 changes list
Date Mon, 22 May 2000 16:04:40 GMT
Hi guys,

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

1) Doctype ---------------------

The indicated namespace for XSP 1.0 was


we would like to propose this new URI schema instead


for the core namespace, then, for taglibs, 


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

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.

3) Optional use of <xsp:page> for pure-taglib usage.

This would allow a page like

   Today is <util:date/>

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.

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="">
  Today is <util:date/>

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.

For these below, I'm sure Ricardo will have more to say, so I leave
space for him.

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.

7) anything else? (add your comments here)

Let's sort this out soon so that both Ricardo and Matt can upgrade their
engines to allow complete interoperability of pages from one engine to
the other, given that both implement the same taglibs.

Any comment is very appreciated.

Please, make it sooner rather than later :)

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message