Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 62575 invoked by uid 500); 30 Apr 2003 14:42:32 -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 62557 invoked from network); 30 Apr 2003 14:42:32 -0000 Received: from unknown (HELO pulse.betaversion.org) (217.158.110.65) by daedalus.apache.org with SMTP; 30 Apr 2003 14:42:32 -0000 Received: (qmail 16548 invoked from network); 30 Apr 2003 14:42:30 -0000 Received: from unknown (HELO apache.org) (stefano@66.198.46.82) by pulse.betaversion.org with SMTP; 30 Apr 2003 14:42:30 -0000 Message-ID: <3EAFE0D9.2090005@apache.org> Date: Wed, 30 Apr 2003 09:42:33 -0500 From: Stefano Mazzocchi User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: Semantic analysis of the namespace URI used in Cocoon HEAD References: <83r87l3fjg.fsf@bog.darkzone.fiz-chemie.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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.