[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Schema Namespace name, schemaLocation, and Schema V ersi

• To: <xml-dev@l...>
• Subject: Re: Schema Namespace name, schemaLocation, and Schema V ersioning
• From: "Rick Jelliffe" <ricko@a...>
• Date: Fri, 19 Jul 2002 13:35:57 +1000
• References: <20020718161054.88979.qmail@w...>

From: "Dare Obasanjo" <kpako@y...>

> For the W3C to actually have a policy where versions
> of their standards never change their namespace URI
> would have many negative effects across the software
> industry where XML is used. Either applications that
> worked perfectly in the past would continually break
> as changes to the RECs were made or the W3C would have
> to ensure that every change they made was backwards
> copmpatible which is an difficult burden and one it
> has shown to be incapable of doing. 

That a namespace cannot be assumed to be version-specific
has been well established since the HTML namespace debates:
many DTDs but the same namespace.  All a namespace
does is set general semantics. If your engineers are assuming
that namespaces provide versioning, they need to be warned!

The W3C has never has much consideration of versioning
untill recently.

Look at XML 1.0:  it seems that most implementations
read the XML 1.0 spec to mean that they must fail
if there is anything else than XML 1.0 in the version
information.   This copes with large scale revisions,
but it makes life more difficult for minor revisions.

Look at namespaces. If XML Namespaces had been defined to also 
specify the particular format to be used and reserved some part
to be treated as insignificant for namespace comparisons
(e.g. a minor version number) then we could have 
a degree of backwards compatible changes.  

(It is not that you cannot use version numbers in your namespace
URLs. It is just that none of the generic tools are written to
support this.)

If query mechanisms allowed one to map between namespaces,
that would be another mechanism.  If the schema for the new
namespace is derived from the old one, then that could help
an implementation map the names (from the new to the old),
and this is of course the reason for XML Schemas, so that 
you can work in terms of some underlying unchanging
type names rather than the given names and namespace
of the document.

Without versioning in the W3C infrastructure, public schemas 
have to err on the side of openness.   And version-dependencies
have to be signified some other way, and validated some other way.

This is why the feature in RELAX NG and Schematron
where you can, in effect, use an attribute value to select which content 
model to validate against is important.   It provides a simple way to 
cope with multiple schema versions within the same source
document and using the same namespace URL. 

Since XML Schemas does not support such co-occurrence constraints,
W3C has to take the elaborate route of providing derivation, PSVI, and 
queries/paths written in terms of type names in order to cope with
versioning. 

Cheers
Rick Jelliffe

• Follow-Ups:
  • Re: Schema Namespace name, schemaLocation,and Schema V ersioning
    • From: "Thomas B. Passin" <tpassin@c...>

• References:
  • Re: Schema Namespace name, schemaLocation, and Schema V ersioning
    • From: Dare Obasanjo <kpako@y...>

• Prev by Date: Re: XPointer and XML Schema
• Next by Date: Re: XPointer and XML Schema
• Previous by thread: Extending schemas
• Next by thread: Re: Schema Namespace name, schemaLocation,and Schema V ersioning
• Index(es):
  • Date
  • Thread