Giacomo Pati wrote:
By moving to a 2.0 version of the namespace, to indicate back incompatibility. Versioning should be kept consistent, expecially on namespaces: same number means perfect compatibility, same major number means back compatibility (if I roll forward, nothing needs to be changed), different major means no compatibility (in a semantic sense).On Fri, 10 Jan 2003, Stefano Mazzocchi wrote:Sylvain Wallez wrote:The sitemap namespace contains a version number : "http://apache.org/cocoon/sitemap/1.0", so what about upgrading to "1.1" ? It would be fairly easy for the TreeProcessor to autoconfigure itself depending on the root element namespace and so handle gracefully both versions, even inside a single Cocoon instance (i.e. sitemaps and subsitemaps in different versions).while the sitemap namespace was introduced exactly for this, I think that we should try to remove possible duplication of effort (and code). So, I would agree to name the Cocoon 2.1 sitemap namespace as http://apache.org/cocoon/sitemap/1.1 since it is different from the old one (and this definately helps sitemap editors!) but I would try to make an effort to have the same code interpret the two of them. This also mean that Sitemap 1.1 *extends* Sitemap 1.0, that is: - all tags included in sitemap 1.0 keep the same meaning in 1.1 - only new elements and attributes are added to the sitemap 1.1How would you deprecate/eliminate elements if you inherit them all the way to higher versions?
I believe that we didn't remove anything from 1.0 to 1.1, did we?
In that case, I'd be in favor of keeping them there and log deprecation warning in the logs.
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]