OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XML Schemas: Best Practices ? Versioning



Curt-

I like your suggested approach of adding an attribute in the instance that gives the schema version number.  It seems to me that you would want to have as consistent an approach as possible between the two cases you cite.

Therefore, is what you are suggesting as follows?

Case 2:  New schema only extends and does not invalidate previously valid documents

In the schema:
a. Keep same target namespace
b. Have an attribute on the element that introduces the namespace to reflect the schema version (your example below)
In the instance:
c. Once you have confirmed that there are no compatibility problems, change the schema version attribute (to reflect the new schema version) and the schemaLocation attribute (to point to the new schema file)

Case 1:  New schema changes interpretation . . .

Same as above except  (a) would now say “Change the target namespace”

Mary
 

"Arnold, Curt" wrote:

Sorry to come late to the party.  There was a pretty dense discussion on this on www-schema-comments@w3.org quite a while ago (maybe a year ago), see
http://lists.w3.org/Archives/Public/www-xml-schema-comments/2000JulSep/0211.html and related messages.

Basically, I saw two cases:

1. The new schema changes the interpretation of some element, for example, a construct that was valid and meaningful for the previous schema does not validate against the new schema.  In this case,
you should change the namespace since processors that worked with the old document might do the wrong thing with a new document.

2. The new schema extends the namespace by adding new elements, etc, but does not invalidate previously valid documents.  In this case, it is appropriate to keep the old namespace since old software
could handle new documents appropriately and new software the old.

In case 2, the most appropriate way to signal what schema is appropriate is through an additional attribute on the element that introduces the namespace.  For example, if a document was valid per
version 1.0 and later of http://www.example.org/foo, it could indicate it by:

<foo:foo foo:version="1.0" xmlns:foo="http://www.example.org/foo"/>

If a document relied on elements that were defined in later versions, it could indicate it by:

<foo:foo foo:version="1.5" xmlns:foo="http://www.example.org/foo"/>

(acceptible values of foo:version in the v1.5 schema would be "1.5", "1.4", "1.3", etc)

If existing processors saw this document, they could either validate against the foo v1 schema and reject the document, or they could validate against a lax v1 compatible schema (that had a decent
amount of <xsd:any>'s) or they could skip validation.

This approach does require the schema resolution mechanism to allow access to the attributes on the namespace introducing element.

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.xml.org/ob/adm.pl>

--
Mary K. Pulvermacher
The MITRE Corporation
pulver@mitre.org
(719) 572-8241 or DSN 834-6726 x 8241
---------------------------------------------------