RE: [xml-dev] Schema Namespace name, schemaLocation, and Schema V ersioning

["Dare Obasanjo" <dareo@microsoft.com>]

-----Original Message----- 
From: David Carlisle [mailto:davidc@nag.co.uk] 
Sent: Fri 7/19/2002 10:27 AM 
To: Dare Obasanjo 
Cc: xml-dev@lists.xml.org 
Subject: Re: [xml-dev] Schema Namespace name, schemaLocation, and Schema V ersioning

>Take a look at the namespace spec.
>Namespaces are not about semantics they are about names.

>A language version is usually undersood to share some named constructs
>with other versions of the same language. If it doesn't then it is not a
>new version, it is a new language.

Names (i.e. syntax) are inconsequential. Semantics is everything. For instance if the next version of XSLT keeps the same namespace name but specifies that an xsl:template can only have one attribute called "xpath" or that "match" & "name" must appear together or not at all then an xsl:template in XSLT 1.0 would not be the same as an xsl:template in XSLT 2.0 regardless of whether their names are the same or not. The nasty side effect is that even if some XSLT processors are smart enough to figure out how to handle different versions, most other aspects of the XML architecture that processes these stylesheets will break. People who validate their stylesheets using W3C XML Schema will suddenly have invalid stylesheets since the targetnamespace has not changed even though the definition of a valid stylesheet has. XPath queries will have to be updated since the assumptions they made would now be wrong. Heck, even namespace aware parsing via SAX or pull models will also be broken since the document structure is different but the namespace URI is the same. 

At least XSLT can avoid this via the version attribute but W3C XML Schema on the other hand HAS NO SUCH THING. 



>Keeping namespaces stable has many benefits.


Like what?


>Consider XSLT for example  an XSLT processor needs to know straight away
>what elements are XSLT and which are foreign. Because all future
>versions of XSLT are in the same namespace, it can do this, and have
>specified behaviour about what to do if it discovers a (presumably new)
>construct in a newer version of the language. If new versions of XSLT
>were in different namespaces it would be impossible to specify this
>forward compatible behaviour and newer XSLT namespaces would just look
>like literal result elements. This would be a lot less useful.


Forward compatibility is a pointless goal. Who actually expects to compile C99 with a C89 compiler or Java 1.4 with the Java 1.0 compiler? Who expects Quake 3 to run on Windows 3.1? So why would anyone expect XSLT 1.0 to be able to process XSLT 2.0 that has all sorts of significant changes like PSVI aware XPath, output to multiple documents, xsl:import-schema, xsl:for-each-group, etc. 


>Changing namespaces changes the name of every construct and so _breaks_
>every tool that uses the language. It's because doing that to "millions
>of computer users" isn't helpful that I query your desire to change
>namespaces as often as possible.

I disagree and am utterly confused by how you came to this conclusion. In most cases a new version of a language is not expected to be run by an old processor although HTML probably set new standards in what is typically termed "graceful degradation".