Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <45223.10.0.0.1.1051587587.squirrel@ags01.agsoftware.dnsalias.com>
Date: Mon, 28 Apr 2003 21:39:47 -0600 (CST)
Subject: Re: Semantic analysis of the namespace URI used in Cocoon HEAD
From: "Antonio Gallardo" <agallardo@agsoftware.dnsalias.com>
To: <cocoon-dev@xml.apache.org>
In-Reply-To: <3EADB041.4090003@apache.org>
References: <3EADB041.4090003@apache.org>
Importance: Normal
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

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.