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

[Mark Feblowitz <mfeblowitz@frictionless.com>]

Jeni - 

As usual, very eloquently stated, very thought-provoking, and very helpful. 

And you have called our attention to a useful distinction: between the
markup version and the schema version. Each of these is has an objective,
concrete definition, and gets us away from the subjective criteria around
"major" versus "minor" versus "trivial" changes.

I also appreciate your comments on the impacts of markup changes on XSL
(and, for that matter, any application). That is a potentially serious
concern when altering the markup - that all XPath expressions would have to
be reviewed and updated. In a very general, very extensible substrate
vocabulary, changes to the markup are few and far between, and breakage
would be rare (XSL for manipulating/formatting .xsd files would be very
stable for a very long time ;-). For the rest of us, markup changes are
harder to avoid. We try to reduce the likelihood of labor-intensive breakage
by minimizing wholesale restructuring and keeping primarily to
additions/extensions. At least in these cases, we can leave much of the
XPath untouched.

Given that most of our version releases would contain both schema and markup
changes, it would seem that this distinction may not be that useful. And it
still doesn't help me understand the ramifications of putting version
information in the namespace name.

This all gives me brain cramps. It's not easy to understand all of the
dimensions of change, and the role of the schema, the application, and
version publication policies in managing that change. Toss in the ripple
effects on the applications, and you've got one rich conundrum.

In our case, the "proper version" approach that you suggest would likely
cause breakage for our users. Any time a new version was promoted to the
proper version, anyone who didn't know about and prepare for the change
would experience breakage. To recover (without doing a full upgrade), they'd
have to point at an older version *and* they have to alter their namespace
references, to reflect that they're using an older version. An incentive to
keep up to date, but one that would require working applications to be
updated (not very popular in industry).

The crux of the matter is managing change: change to the markup, change to
the schema(s), change to the applications that generate and process the
markup, change to the stylesheets that transform/format the markup, and
change to the middleware that maps the markup into other dialects and/or
into databases. There is also the impact of schema change on those who build
on other schema(s). If a type in one schema is renamed, that would adversely
effect all who import/include the schema and reference that type. And,
because this is an interchange activity, changes often ripple between
enterprises. 

And the "art" here is in assessing what part the validating parsers play in
accepting/rejecting version differences. Remove version information from the
namespace name and the validator plays no direct role, at least when
namespace names are compared. Add the version information and the validator
plays a very direct role, rejecting mismatches and requiring interchangers
to a priori agree on version. 

I'm still not much closer to knowing what our approach will be. I'd be happy
to hear other viewpoints.

Mark



 -----Original Message-----
From: 	Jeni Tennison [mailto:jeni@jenitennison.com] 
Sent:	Wednesday, July 17, 2002 6:07 AM
To:	Mark Feblowitz
Cc:	'CHIUSANO, Joseph'; 'Xml-Dev (E-mail)'; Duane Krahn (E-mail); Satish
Ramanathan (E-mail); Andrew Warren (E-mail); Kurt A Kanaskie (Kurt)
(E-mail); Michael Rowell (E-mail)
Subject:	Re: [xml-dev] Schema Namespace name, schemaLocation, and
Schema V  ersioning

Hi Mark,

First, I think it's important to make the distinction between versions
of a markup language and versions of a schema. One version of one
markup language might have multiple associated versions of schemas,
perhaps fulfilling different purposes, or simply developed over time.
The location of the single predominant schema for a particular version
of the markup language at any one time should probably be fixed, such
that, for example:

  http://www.MyStandard.org/2.3.1/xyz.xsd

always points to the XML Schema for version 2.3.1 of the markup
language XYZ.

[Note that the value of the 'version' attribute on the xs:schema
element in XML Schema doesn't get passed through into the PSVI, so
should be used to indicate the version of the schema rather than the
version of the markup language. The schemaVersion attribute on
sch:schema in Schematron has a similar role, I believe.]

Then the question is whether you want to change the namespace with
each version of the markup language. I think that this comes down to
how you want processors of earlier versions of the markup language to
treat documents in the new version of the markup language. If you want
the applications to reject documents in the new version of the markup
language completely, then you should use a different namespace for
them. If you want the applications to attempt to process the documents
in the new version of the markup language, then you should use a
different mechanism (such as a required and fixed 'version' attribute
on the document element) to indicate the version of the markup
language. Also, if you want individual applications to be able to deal
with more than one version of the markup language, it's helpful to use
the same namespace throughout versions.

Most of my reasoning behind this comes from thinking about how XSLT
stylesheets would handle new versions of a markup language. XSLT (and
any namespace-aware processor) treats elements in different namespaces
completely differently. If you give an XSLT stylesheet designed for
one namespace exactly the same document but with a slightly different
namespace, it won't be able to process it properly (it won't consider
it to be the "same document" at all). Changing a stylesheet to handle
a new version of the markup language (with a new namespace) *instead*
of the old version would be fairly easy (just change the namespace
declaration and alter the templates to handle any new or altered
elements), but changing it to handle a new version of the markup
language (with a new namespace) *as well* would involve adding a new
namespace declaration and probably changing every single path and
pattern within the stylesheet.

Of course if the applications that deal with a markup language don't
use the namespace in any fundamental way -- if they just check it once
and then using the local names of the elements in the rest of the
processing -- then it's perfectly fine to use the namespace as the way
of indicating the version of the markup language used in a document.
Also, if there's only ever one version of the markup language in use
at any one time (which I think is unlikely), changing the namespace
alongside the version of the markup language would be appropriate.

In general, though, I'd say that you should have a single, fixed
namespace for the markup language, unchanged through the versions of
the markup language. To indicate versions, you should instead have a
fixed and required 'version' attribute on the document element (and
perhaps elsewhere). If you adopt this scheme, it's important to have
rules about what applications should do when they encounter a (new or
old) version that they don't support.

I think it's also useful to have one or more different namespaces for
"trial" or "draft" versions of the markup language -- during initial
development, for example -- so that applications that are designed to
work on draft versions of the markup language reject documents in the
"proper" version (and you can tell that you need to update your
application) and so that documents that use the draft version of the
markup language are rejected by applications that are designed to work
with the proper version.

So I'd have a namespace scheme like:

  http://www.MyStandard.org/XYZ           (proper version)
  
  http://www.MyStandard.org/XYZ/0.1.0     (draft 0.1.0)
  http://www.MyStandard.org/XYZ/1.0.0     (draft 1.0.0)
  http://www.MyStandard.org/XYZ/2.3.1     (draft 2.3.1)

and have schemas at locations mirroring these namespaces:

  http://www.MyStandard.org/xyz.xsd
  
  http://www.MyStandard.org/XYZ/0.1.0/xyz.xsd
  http://www.MyStandard.org/XYZ/1.0.0/xyz.xsd
  http://www.MyStandard.org/XYZ/2.3.1/xyz.xsd

(If 2.3.1 was the current version, then
http://www.MyStandard.org/xyz.xsd would be the same as
http://www.MyStandard.org/XYZ/2.3.1/xyz.xsd, but with a different
target namespace.)

I'd anticipate having different versions of schemas for each different
version of the markup language, so you might have:

  http://www.MyStandard.org/XYZ/2.3.1/xyz.1.xsd
  http://www.MyStandard.org/XYZ/2.3.1/xyz.2.xsd
  http://www.MyStandard.org/XYZ/2.3.1/xyz.5.xsd

where the latest version of the schema for version 2.3.1 of the markup
language was version 5, and thus
http://www.MyStandard.org/XYZ/2.3.1/xyz.5.xsd was the same as
http://www.MyStandard.org/XYZ/2.3.1/xyz.xsd.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/