cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Holz <>
Subject Re: Semantic analysis of the namespace URI used in Cocoon HEAD
Date Wed, 30 Apr 2003 16:18:25 GMT
Stefano Mazzocchi <> writes:

> on 4/29/03 10:56 AM Stephan Michels wrote:
> [Martin Holz wrote]
> >>Okay, the namespaces already exist and its only names, so it
> >>would be the easiest to keep the existing pattern, bit please
> >>avoid creating namespace variants based on version numbers.
> > 
> > 
> > I agree here, you doesn't gain a benefit using a version within
> > a namespace. 
> Contracts need to be uniquely identified. There is no way out of this.
> There are are three simple way to uniquely identify an xml markup:
>  1) versioning the namespace (as we do in the sitemap, for example)
>  2) a version="" attribute and metodology (as done in XSLT)
>  3) a version="" pseudoattribute in a PI (as XML itself does)
> In my personal quest against PI, I rule #3 out. The other two remains.

I don't like #3 either.
> I personally believe that #2 is simply too complex for what we need. So
> #1 remains.

I do not see, how #2 is more complex than #1, except that #1 already exists.
> The namespaces should only help to get an information,
> > where these element come from. Moreover, using versions allows to
> > use different version of the same element within a document.
> > 
> > So here my -1,
> We need to be able to clearly identify a contract. Without a versioning
> system, we can't.

Which contract does a namespace identify? A namespace belongs to a 
element/attribute, so it identifies a contract  on the element.
If the semantics of the element  change, you should change the namespace 
or use a other element name. The namespace does not belong to the complete
document. That's  even more important, if you do not look on normal documents,
but intermediate formats, that are handled by a transformer somewhere in
the middle of a cocoon pipeline.  
Contracts on documents are traditionally described by the PUBLCID,
which usually contains a version number. You could create families of
contracts using modularized DTDs.  

If DTDs are not used, a version attribute for the top level
element would be a good idea. 

> So, either you propose an alternative unique identification of the
> contract (not of their families!) or your -1 is useless because it
> abolishes existing practices without providing an alternative to
> something that is already in place.

Since the namespaces are already in place, they should not change,
even if the document format changes. A important aspect of a pattern
oriented functional programming language like XSLT is, that you can
process families of document formats. 


Martin Holz     <>

Softwareentwicklung / Vernetztes Studium - Chemie
Franklinstrasse 11
D-10587 Berlin     


View raw message