Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 54939 invoked by uid 500); 10 Jan 2003 16:33:49 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 54927 invoked from network); 10 Jan 2003 16:33:49 -0000 Message-ID: <3E1EF656.2040704@apache.org> Date: Fri, 10 Jan 2003 08:35:34 -0800 From: Stefano Mazzocchi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [RT]: Names for pipeline components section References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Giacomo Pati wrote: > 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.1 > > > How would you deprecate/eliminate elements if you inherit them all the > way to higher versions? 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). 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 -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org