[
Lists Home |
Date Index |
Thread Index
]
- To: Mark Feblowitz <mfeblowitz@frictionless.com>
- Subject: Re: [xml-dev] Schema Namespace name, schemaLocation, and Schema V ersioning
- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Wed, 17 Jul 2002 11:07:20 +0100
- Cc: "'CHIUSANO, Joseph'" <JCHIUSANO@lmi.org>, "'Xml-Dev (E-mail)'" <xml-dev@lists.xml.org>, "Duane Krahn (E-mail)" <duane.krahn@irista.com>, "Satish Ramanathan (E-mail)" <Satish.Ramanathan@mro.com>, "Andrew Warren (E-mail)" <awarren@openapplications.org>, "Kurt A Kanaskie (Kurt) (E-mail)" <kkanaskie@lucent.com>, "Michael Rowell (E-mail)" <mrowell@openapplications.org>
- In-reply-to: <4DBDB4044ABED31183C000508BA0E97F040ABD94@fcpostal.frictionless.com>
- Organization: Jeni Tennison Consulting Ltd
- References: <4DBDB4044ABED31183C000508BA0E97F040ABD94@fcpostal.frictionless.com>
- Reply-to: Jeni Tennison <jeni@jenitennison.com>
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/
|