RE: Versioning of XML Schema and namespaces

Uh oh. There is clearly significant divergence here. 

There appear to be 2 1/2 positions:

1. very formal versioning of namespace identifiers - major.minor
revision number etc - this is in all three of the XML Naming and Design
Rules documents recently published by DON, UN/CEFACT and OASIS
http://xml.coverpages.org/ni2005-01-31-a.html

2. no versioning - eloquently argued by Eliot Kimber in particular, on
both conceptual and practical grounds, but the latter disputed by a few
people. 

2'. slipping a date into the identifier - this is W3C's approach (e.g.
http://www.w3.org/2001/XMLSchema) though not clear that this is a fully
thoughtful position in relation to *XML Namespaces*, or is just a
consequence of W3C's URL design pattern which partly follows TimBL's
Cool URI's principles where he presented a weak argument for dating
everything. However, it does provide a potential snug home for
relatively coarse-grained versioning if required. 

Maybe a horses-for-courses case - different approaches apply to
different use-cases? 
Can we enumerate what these are?
Probably related to language volatility, and consequent maintenance
burden and capacity, 
which in turn is probably related to organisational capacity. 

Simon Cox

> -----Original Message-----
> From: xmlschema-dev-request@w3.org 
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Eliot Kimber
> Sent: Thursday, 12 May 2005 10:37 PM
> To: xmlschema-dev@w3.org
> Cc: Michael Kay; 'Dan Vint'; 'Fraser Crichton'; 
> John.Hockaday@ga.gov.au
> Subject: Re: Versioning of XML Schema and namespaces
> 
> 
> Michael Kay wrote:
> >>That's my reason for using the namespace with a version.
> >>
> >>I understand all the stated reasons for not doing this, but 
> out of the 
> >>box there is nothing else that will consistently and automatically 
> >>trip up validation if I don't have the "right" file being used to 
> >>validate my documents.
> > 
> > 
> > You might make it easier for the recipient to do validation by 
> > including a version in the namespace, but you are making it 
> hideously 
> > difficult for the recipient to process the incoming documents using 
> > namespace-aware tools such as XSLT and XQuery - as anyone who has 
> > tried to write code that handles the different flavours of 
> RSS can tell you.
> 
> Yow! I completely forgot about this very practical reason for 
> not versioning namespaces! This is really much more 
> compelling than any philosophical argument I could make.
> 
> Mike is 100% correct--any namespace-aware processor, the most 
> obvious example being XSLTs, may have to be significantly 
> rewritten at the detail level in order to handle each new 
> variant of the namespace for the same (abstract) application.
> 
> For example, consider this XSLT life cycle:
> 
> Time T[0]:
> 
>   - Application namespace is: xmlns:myns0="http://example.com/myns/v0"
> 
>   - Write template to match on element "foo" within "bar" in 
> this namespace:
> 
>     <xsl:template match="myns0:bar/myns0:foo">
> 
>     (multiply by the number of element types in the application)
> 
> Time T[1]:
> 
>    - New version of the myns schema is released and the 
> namespace is updated to: xmlns:myns0="http://example.com/myns/v1"
> 
>    - Rewrite *each* template to reflect the new namespace and the old
> namespace:
> 
>     <xsl:template match="myns0:bar/myns0:foo | myns1:bar/myns1:foo">
> 
>     (multiply by the number of element types in the application)
> 
>   - Add any new templates for element types that are new (or in new
> contexts) for this new release of the application.
> 
> 
> Clearly this represents a huge maintenance cost for any non-trivial 
> application and processor that needs to support multiple 
> versions of an 
> application. And multiple by the number of namespaces used in a given 
> application--if all of them version their namespaces it's 
> going to be a 
> real mess within a short period of time.
> 
> By contrast, if the namespace doesn't change, new versions of 
> the schema 
> require only adding the specific code needed to react to 
> those changes, 
> not a change to, potentially, every match= and select= 
> statement in the 
> transform.
> 
> And note that using matches of the form "*[name() = 'foo']" are not 
> generally safe when processing documents that contain elements from 
> different namespaces because there could easily be conflicts of local 
> names (that being the whole motivation for namespaces in the 
> first place).
> 
> Cheers,
> 
> Eliot
> -- 
> W. Eliot Kimber
> Professional Services
> Innodata Isogen
> 9390 Research Blvd, #410
> Austin, TX 78759
> (512) 372-8155
> 
> ekimber@innodata-isogen.com
> www.innodata-isogen.com
> 
>

Received on Tuesday, 17 May 2005 06:27:46 UTC