Re: Versioning of XML Schema and namespaces

Hi,

I thought this made interesting reading in light of what you have been 
saying. I think what it's saying is that even though versioning is 
included in the namespace a vocabulary becomes static at that point -
*
UBL and Object-Oriented XML: Making Type-Aware Systems Work
<http://www.idealliance.org/papers/dx_xml03/papers/04-04-04/04-04-04.pdf>*http://www.idealliance.org/papers/dx_xml03/papers/04-04-04/04-04-04.pdf

I'd be interested to hear some counter arguments, perhaps?

Cheers,

Fraser

Simon.Cox@csiro.au wrote:

>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
>>
>>
>>    
>>
>
>  
>



Attention:
This email may contain information intended for the sole use of
the original recipient. Please respect this when sharing or
disclosing this email's contents with any third party. If you
believe you have received this email in error, please delete it
and notify the sender or postmaster@solnetsolutions.co.nz as
soon as possible. The content of this email does not necessarily
reflect the views of SolNet Solutions Ltd.