cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Semantic analysis of the namespace URI used in Cocoon HEAD
Date Mon, 28 Apr 2003 22:50:41 GMT
In light of contrast solidity, I armed myself with grep and patience and
went thru the entire CVS HEAD to find out all the cocoon-related
namespace URIs that we use.

Here is the result: + CONF_VERSION

First of all, the *default* pattern for Cocoon namespaces is[name]/[major.minor]


 name -> indicates the concept to which the namespace is connected
 major.minor -> the version of the namespace

only half of the namespaces follow that pattern.


Two namespaces follow the year-oriented approach that W3C suggests.
While I don't want to enter a discussion, I *strongly* believe that
W3C-mandated year-based URI design *SUCKS ASS*. Most notably for one
reason: usability.

It's very natural for people to know the version of the namespace they
are using, but it's not to remember what year that particular version
was released. XHTML is namespaces with I
strongly believe that "" would have been shorter,
easier to remember, and *MUCH* more friendly.

XMLForm and JXForms use a year-based approach. I propose we change these to:


The error notifying generator uses the following namespace: + CONF_VERSION

which is correct, but forces people to upgrade their stylesheets
everytime a new release is made. This is, IMO, unnecessary. I propose to
change this to

and change it only when it makes sense to do so.


the use of is semantically equivalent to but I think coherence is important. I
therefore propose to change



The namespaces defined in the 'slide' block:

don't follow any of the patterns.

> ------------------------------------------------------------------

We have two different namespaces for:

 - source

 - mail

Why is it so? I would propose we make an effort to converge the two into


The request generator is part of the core generators yet it doesn't
follow the patterns. I suggest we change



there are two XSP logicsheets who don't belong to the XSP URI space:

I propose to change them into


Is the following namespace ever used?

if so, I propose we change it into


The namespace

is used in xmlform, I propose to change it into

or something equivalent


Final thoughts

I'm perfectly aware that all those changes are back-incompatible, but,
IMO, we *MUST* make an effort to keep a registry of the namespaces used
and make sure we both control them and keep an eye on their pattern

I also propose that *everytime* code is added in CVS that introduces or
works on a new namespace, a vote has to take place on the URI used for
that namespace.



View raw message