cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Semantic analysis of the namespace URI used in Cocoon HEAD
Date Wed, 30 Apr 2003 16:55:50 GMT
on 4/30/03 11:18 AM Martin Holz wrote:

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

XSLT includes a full section to forward-compatible versioning. this is
complex and not at all standard nor ratified in any XML specifications.

Moreover, there is no standard way to get this versioning information.

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

the schema + the semantics associated to that schema.

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

a different namespace for each element and attribute? get real.

> The namespace does not belong to the complete
> document. 

Of course. that's the reason why namespaces were introduced in the first

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

Modularized DTDs are not multidimensional.

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

you seem to imply there *IS* a top-level element in a namespace. This is
not automatically the case.

So, are you suggesting we add a version attribute to *all* elements? or
we introduce a different namespace everytime an element is changed?

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

So, you are suggesting that even if the contract changes, the
indentifier must remain the same?

I strongly disagree with this vision.

> A important aspect of a pattern
> oriented functional programming language like XSLT is, that you can
> process families of document formats. 

So? I don't get your point.


View raw message