You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/04/29 00:50:41 UTC
Semantic analysis of the namespace URI used in Cocoon HEAD
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:
http://apache.org/cocoon/sitemap/1.0
http://apache.org/cocoon/directory/2.0
http://apache.org/cocoon/include/1.0
http://apache.org/cocoon/source/1.0
http://apache.org/cocoon/profiler/1.0
http://apache.org/cocoon/i18n/2.1
http://apache.org/cocoon/status/2.0
http://apache.org/cocoon/action/1.0
http://apache.org/cocoon/xmldb/1.0
http://apache.org/cocoon/capture/1.0
http://apache.org/cocoon/lucene/1.0
http://apache.org/cocoon/search/1.0
http://apache.org/cocoon/sendmail/1.0
http://apache.org/cocoon/mail/1.0
http://apache.org/cocoon/LDAP/1.0
http://apache.org/cocoon/xsp/input/1.0
http://apache.org/cocoon/fragmentextractor/2.0
http://apache.org/cocoon/paginate/1.0
http://apache.org/cocoon/SQL/2.0
http://apache.org/cocoon/error/ + CONF_VERSION
http://apache.org/cocoon/linkstatus/2.0
http://apache.org/cocoon/zip-archive/1.0
http://apache.org/cocoon/role-filter/1.0
http://apache.org/cocoon/XSPDoc/v1
http://apache.org/cocoon/SQL/v2
http://xml.apache.org/cocoon/xdoc/1.0
http://xml.apache.org/cocoon/GIFSourceInspector
http://xml.apache.org/cocoon/JPEGSourceInspector
http://xml.apache.org/cocoon/XPathSourceInspector
http://xml.apache.org/cocoon/PrincipalListGenerator
http://xml.apache.org/cocoon/source/2.0
http://xml.apache.org/cocoon/validator/phase
http://xml.apache.org/cocoon/xmlform/2002
http://xml.apache.org/cocoon/requestgenerator/2.0
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/jxforms/2002/cr
http://cocoon.apache.org/templates/jx/1.0
http://apache.org/xsp
http://apache.org/xsp/request/2.0
http://apache.org/xsp/response/2.0
http://apache.org/xsp/session/2.0
http://apache.org/xsp/cookie/2.0
http://apache.org/xsp/log/2.0
http://apache.org/xsp/util/2.0
http://apache.org/xsp/form-validator/2.0
http://apache.org/xsp/sel/1.0
http://apache.org/xsp/xscript/1.0
http://apache.org/xsp/soap/3.0
http://apache.org/xsp/jpath/1.0
http://apache.org/xsp/request/2.0
http://apache.org/xsp/response/2.0
http://apache.org/xsp/session/2.0
First of all, the *default* pattern for Cocoon namespaces is
http://apache.org/cocoon/[name]/[major.minor]
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.
------------------------------------------------------------------
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
------------------------------------------------------------------
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.
------------------------------------------------------------------
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
------------------------------------------------------------------
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.
> ------------------------------------------------------------------
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.
------------------------------------------------------------------
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
------------------------------------------------------------------
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
------------------------------------------------------------------
Is the following namespace ever used?
http://apache.org/cocoon/XSPDoc/v1
if so, I propose we change it into
http://apache.org/xsp/doc/1.0
------------------------------------------------------------------
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
------------------------------------------------------------------
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.
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.
Thoughts?
--
Stefano.
Re: Semantic analysis of the namespace URI used in Cocoon HEAD
Posted by Stefano Mazzocchi <st...@apache.org>.
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
place.
> 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.
--
Stefano.
Re: Semantic analysis of the namespace URI used in Cocoon HEAD
Posted by Martin Holz <ho...@fiz-chemie.de>.
Stefano Mazzocchi <st...@apache.org> 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
--
Martin Holz <ho...@fiz-chemie.de>
Softwareentwicklung / Vernetztes Studium - Chemie
FIZ CHEMIE Berlin
Franklinstrasse 11
D-10587 Berlin
Re: Semantic analysis of the namespace URI used in Cocoon HEAD
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/29/03 10:56 AM Stephan Michels 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 personally believe that #2 is simply too complex for what we need. So
#1 remains.
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.
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.
--
Stefano.
Re: Semantic analysis of the namespace URI used in Cocoon HEAD
Posted by Stephan Michels <st...@apache.org>.
On 29 Apr 2003, Martin Holz wrote:
> Stefano Mazzocchi <st...@apache.org> writes:
> > First of all, the *default* pattern for Cocoon namespaces is
> >
> > http://apache.org/cocoon/[name]/[major.minor]
> >
> > where
> >
> > name -> indicates the concept to which the namespace is connected
> > major.minor -> the version of the namespace
>
> Would a minor number ever be useful? Its important to understand,
> that a namespace is not directly related to a certain version
> of a DTD or any other format specification. If there is a minor
> or even a major version change of a document format, the namespace
> should stay the same, because most elements would still mean the same
> and could be processes by the same software.
>
> If the semantics of a elements change during the evolution of
> a document format you would better introduce a new element,
> not a new namespace.
>
> Namespaces are for mixing data from different companies and
> domains, where the designers of one format are not aware of the
> the other format. Formats from the same organization, especially
> different format versions should not need namespaces at all, since
> they are hopefully designed interoperable from the start.
>
> 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. 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,
Stephan Michels.
Re: Semantic analysis of the namespace URI used in Cocoon HEAD
Posted by Martin Holz <ho...@fiz-chemie.de>.
Stefano Mazzocchi <st...@apache.org> writes:
> First of all, the *default* pattern for Cocoon namespaces is
>
> http://apache.org/cocoon/[name]/[major.minor]
>
> where
>
> name -> indicates the concept to which the namespace is connected
> major.minor -> the version of the namespace
Would a minor number ever be useful? Its important to understand,
that a namespace is not directly related to a certain version
of a DTD or any other format specification. If there is a minor
or even a major version change of a document format, the namespace
should stay the same, because most elements would still mean the same
and could be processes by the same software.
If the semantics of a elements change during the evolution of
a document format you would better introduce a new element,
not a new namespace.
Namespaces are for mixing data from different companies and
domains, where the designers of one format are not aware of the
the other format. Formats from the same organization, especially
different format versions should not need namespaces at all, since
they are hopefully designed interoperable from the start.
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.
Martin
--
Martin Holz <ho...@fiz-chemie.de>
Softwareentwicklung / Vernetztes Studium - Chemie
FIZ CHEMIE Berlin
Franklinstrasse 11
D-10587 Berlin
Re: Semantic analysis of the namespace URI used in Cocoon HEAD
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Stefano Mazzocchi" <st...@apache.org>
> 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.
>
<skip what="namespace summary"/>
>
> 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.
>
> 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.
+1 for all.
Regards,
Konstantin
>
>
>
> Thoughts?
>
>
> --
> Stefano.
>
>
>
>
RE: Semantic analysis of the namespace URI used in Cocoon HEAD
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
+1 for changing the namespace URIs to make them consistent.
> SNIP
>
> > 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
>
Perhaps we don't need a real vote, but if someone wants to introduce a
new namespace he should first ask if it's ok to use it.
Going this way (or a vote) we will avoid (hopefully) to get
inconsistent namings.
Carsten
Re: Semantic analysis of the namespace URI used in Cocoon HEAD
Posted by Giacomo Pati <gi...@apache.org>.
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
Re: Semantic analysis of the namespace URI used in Cocoon HEAD
Posted by Vadim Gritsenko <va...@verizon.net>.
Antonio Gallardo wrote:
...
>I think we need to write some document to track the changes for people
>comming from older versions, lets say, 2.0.4
>
Link to this document from
http://xml.apache.org/cocoon/installing/updating.html
>In that effort I propose:
>
>1-create a new help document that will be filled as people start to change
>namespaces to the correct convention. Something like:
>
>NAMESPACES CHANGED
>Old Cocoon ---> New Cocoon
>========== ==========
>http://cocoon.apache.org/session/1.0 http://apache.org/cocoon/session/1.0
>
>XMAP TAGS CHANGED
>Old Cocoon ---> New Cocoon
>
>....
>and so on.
>
>I think that writing this kind of doc can helps people to migrate.
>
>
+1
Vadim
Re: Semantic analysis of the namespace URI used in Cocoon HEAD
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Stefano Mazzocchi dijo:
> 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.
>
Hi:
We already have this kind of problems. When we change from one version to
another into the same namespace. Take for example:
1-the namespace of the "error generator" that changed "recently" from 1.0
to 2.0.
2-The i18n tranformer changed the version too.
3-Some tags are changed into cocoon.xconf and sitemap.xmap.
Well, of course that all these changes are needed to get a better code and
from a coherence point of view.
To be clear My vote is: +1 ;-)
But, ....
I think we need to write some document to track the changes for people
comming from older versions, lets say, 2.0.4
In that effort I propose:
1-create a new help document that will be filled as people start to change
namespaces to the correct convention. Something like:
NAMESPACES CHANGED
Old Cocoon ---> New Cocoon
========== ==========
http://cocoon.apache.org/session/1.0 http://apache.org/cocoon/session/1.0
XMAP TAGS CHANGED
Old Cocoon ---> New Cocoon
....
and so on.
I think that writing this kind of doc can helps people to migrate.
2-Another option can be a simple Java tool that can run to replace all the
strings into all the code that need to migrate ;-)
OK, this are just some ideas.
Best Regards,
Antonio Gallardo.
Re: Semantic analysis of the namespace URI used in Cocoon HEAD
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/29/03 3:24 PM Jeremy Quinn wrote:
> On Monday, April 28, 2003, at 11:50 PM, Stefano Mazzocchi wrote:
>
>
>>We have two different namespaces for:
>>
>> - source
>>
>> http://xml.apache.org/cocoon/source/2.0
>> http://apache.org/cocoon/source/1.0
>
>
> [snip]
>
>
>>Why is it so? I would propose we make an effort to converge the two
>>into
>>one.
>>
>
>
> They have different tag semantics unfortunately.
> I agree the 2.0 version should be changed to :
>
> http://apache.org/cocoon/source/2.0
Ok.
Now: do we really need two of them?
--
Stefano.
Re: Semantic analysis of the namespace URI used in Cocoon HEAD
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Monday, April 28, 2003, at 11:50 PM, Stefano Mazzocchi wrote:
> We have two different namespaces for:
>
> - source
>
> http://xml.apache.org/cocoon/source/2.0
> http://apache.org/cocoon/source/1.0
[snip]
>
> Why is it so? I would propose we make an effort to converge the two
> into
> one.
>
They have different tag semantics unfortunately.
I agree the 2.0 version should be changed to :
http://apache.org/cocoon/source/2.0
regards Jeremy
Re: Semantic analysis of the namespace URI used in Cocoon HEAD
Posted by Steven Noels <st...@outerthought.org>.
On 29/04/2003 6:22 Conal Tuohy wrote:
> I think a registry of the namespaces is a great idea!
>
> As well as regularising the URIs, I think the namespaces themselves should
> be documented, by making these URIs actually point to e.g. RDDL documents,
> or failing that, XHTML or HTML documents at least :-)
>
> I don't know if the base URL http://apache.org/cocoon would facilitate that?
> Currently that URI points to 404, so that's a good sign that it could become
> the base URI of a NS registry without breaking anything else.
>
>
>>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.
>
>
> ... and a descriptive document posted to the website.
Shouldn't we look at http://www.rddl.org/ in this perspective? It ain't
ratified in any official way, but we are known as early adopters (even
pioneers) in supporting this kind of infrastructure-related schemes -
hence the xinclude-like components who have been available long before
xinclude has become a W3C spec.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
RE: Semantic analysis of the namespace URI used in Cocoon HEAD
Posted by Conal Tuohy <co...@paradise.net.nz>.
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.
<snip content="huge list of NS URIs and analysis"/>
It's a long list - and it gives an idea of the huge feature set Cocoon has!
> 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.
I think a registry of the namespaces is a great idea!
As well as regularising the URIs, I think the namespaces themselves should
be documented, by making these URIs actually point to e.g. RDDL documents,
or failing that, XHTML or HTML documents at least :-)
I don't know if the base URL http://apache.org/cocoon would facilitate that?
Currently that URI points to 404, so that's a good sign that it could become
the base URI of a NS registry without breaking anything else.
> 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.
... and a descriptive document posted to the website.