cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: Semantic analysis of the namespace URI used in Cocoon HEAD
Date Sat, 17 May 2003 15:32:33 GMT
On Mon, 28 Apr 2003, Stefano Mazzocchi wrote:

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

Oh, no, not again ;-)

> Here is the result:

<snipped namespace list/>

> First of all, the *default* pattern for Cocoon namespaces is
>
>  http://apache.org/cocoon/[name]/[major.minor]

Correct.

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

Hmm.. IIRC we've already normalized NSs once one or two years ago and proposed
that naming 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 http://www.w3.org/1999/xhtml. I
> strongly believe that "http://w3.org/xhtml/1.0" 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:
>
>  http://apache.org/cocoon/xmlform/1.0
>  http://apache.org/cocoon/jxform/1.0

I'm strongly +1 for this.

> The error notifying generator uses the following namespace:
>
>   http://apache.org/cocoon/error/ + 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
>
>   http://apache.org/cocoon/error/2.1
>
> and change it only when it makes sense to do so.

+1

> the use of http://cocoon.apache.org/ is semantically equivalent to
> http://apache.org/cocoon/ but I think coherence is important. I
> therefore propose to change
>
>  http://cocoon.apache.org/session/1.0
>  http://cocoon.apache.org/woody/template/1.0
>  http://cocoon.apache.org/woody/definition/1.0
>  http://cocoon.apache.org/woody/instance/1.0
>  http://cocoon.apache.org/templates/jx/1.0
>
> to
>
>  http://apache.org/cocoon/session/1.0
>  http://apache.org/cocoon/woody/template/1.0
>  http://apache.org/cocoon/woody/definition/1.0
>  http://apache.org/cocoon/woody/instance/1.0
>  http://apache.org/cocoon/templates/jx/1.0

+1

> The namespaces defined in the 'slide' block:
>
>  http://xml.apache.org/cocoon/GIFSourceInspector
>  http://xml.apache.org/cocoon/JPEGSourceInspector
>  http://xml.apache.org/cocoon/XPathSourceInspector
>  http://xml.apache.org/cocoon/PrincipalListGenerator
>
> don't follow any of the patterns.

And we should suggest to change it if possible (I know someone will correct me
for back compatability reasons). Anyway, here's my +1 for it.

> We have two different namespaces for:
>
>  - source
>
>      http://xml.apache.org/cocoon/source/2.0
>      http://apache.org/cocoon/source/1.0
>
>  - mail
>
>      http://apache.org/cocoon/sendmail/1.0
>      http://apache.org/cocoon/mail/1.0
>
> Why is it so? I would propose we make an effort to converge the two into
> one.

+1

> The request generator is part of the core generators yet it doesn't
> follow the patterns. I suggest we change
>
>      http://xml.apache.org/cocoon/requestgenerator/2.0
>
> into
>
>      http://apache.org/cocoon/request/2.0

+1

> there are two XSP logicsheets who don't belong to the XSP URI space:
>
>   http://apache.org/cocoon/SQL/v2
>   http://apache.org/cocoon/xsp/input/1.0
>
> I propose to change them into
>
>   http://apache.org/xsp/esql/2.0
>   http://apache.org/xsp/input/1.0

+1

> Is the following namespace ever used?
>
>   http://apache.org/cocoon/XSPDoc/v1

IIRC the esql logicsheet makes havy use of it.

> if so, I propose we change it into
>
>   http://apache.org/xsp/doc/1.0

+1 changing this should be no problem except others have adopted it for their
own documentation of their custom logicsheets. But anyway I don't think we have
any appication or whatever that uses this namespace for conversion into let's
say document-v11.dtd.

> The namespace
>
>    http://xml.apache.org/cocoon/validator/phase
>
> is used in xmlform, I propose to change it into
>
>    http://apache.org/cocoon/xmlform/validator/1.0
>
> or something equivalent

+1

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

A document containig those namespaces would be a first approach for a registry.
Everyone in need of a new namespace should register it there with some
description of its purpose. Sure, this procedure has to be made publicly
available somewhere in the docs.

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

Might be a way to go +0

Giacomo

Mime
View raw message