RE: XML Schema Versioning Use Cases

Bill:
I'm forwarding your original message to the public discussion URL [1] at
W3C.  You can read other postings at [1];  I strongly recommend you
follow the threads there.  You can also subscribe to the list by sending
mail to the automated list manager [3] with the word "subscribe" in the
subject.  

[1] mailto:public-xml-versioning@w3.org
[2] http://lists.w3.org/Archives/Public/public-xml-versioning/
[3] mailto:public-xml-verisoning-request@w3.org

>"The term "backward compatiable[sic]" will mean that an instance
document 
>defined by an old schema can be processed by an application that
handles 
>the new schema."
>"The term "forward compatiable[sic]" will mean that an instance
document 
>defined by a new schema can be processed by an application that handles

>the old schema."

Mea culpa for the spelling.  Consistent anyway.  But I believe these
statements characterize the state of thinking.

>Here's version 2 of MySchema.  Nobody on the receiving end cares about
all that 
>OptionalStuff, so I removed it.

Foul, at least in XML Schema 1.0.  We're working on mechanisms to make
this kind of action OK in XML Schema 1.1, but right now it's not
allowed.

>You can easily reverse this example, by adding a new required element
in version 3 
>of MySchema, as shown below.

Foul again.  In XML Schema 1.0, you can't require a new element and
expect compatibility with older schemas.

>What we need is a definition of compatibility that is expressed solely
in terms of 
>the instance documents and the schema themselves. How about these
definitions?
[please see the original message for defs]
The problem with these new definitions is that they attempt to capture
some essence of XML Schema 1.0 into the equation.  The existing
definitions are idealized in that they point to "what we want" or "wish
we had."  Note also that the statements >very carefully< refer to the
rather wordy "can be processed by an application that handles" rather
than "validates".  That's because validate may or may not (in the final
analysis of the problem) turn out to be part of the solution.

Best regards,
David Ezell

 -----Original Message-----
From: 	Wade, William (Bill) [mailto:bwade@PROFDATA.COM]
Sent:	Fri Feb 24 09:57:49 2006
To:	David Ezell
Subject:	XML Schema Versioning Use Cases

I wonder about your definitions of forward compatible and backward
compatible in this document (excerpted below).
"The term "backward compatiable[sic]" will mean that an instance
document defined by an old schema can be processed by an application
that handles the new schema."
"The term "forward compatiable[sic]" will mean that an instance document
defined by a new schema can be processed by an application that handles
the old schema."

I have a problem with these definitions, in that they are relative to
the ability of systems processing the documents to continue to do so.
As a result, a given version of a schema may be compatible with system
1, but not with system 2.  Where does that leave us?

Lets take a simple example...

Here's version 1 of MySchema.  Notice that the element OptionalStuff is
(you guessed it) optional.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:foo="http://www.someURL.org/MySchema"
targetNamespace="http://www.someURL.org/MySchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xs:element name="MySchema">
     <xs:complexType>
        <xs:sequence>
           <xs:element name="Stuff"/>
           <xs:element name="OptionalStuff" minOccurs="0"/>
           <xs:element name="MoreStuff"/>
        </xs:sequence>
     </xs:complexType>
  </xs:element>
</xs:schema>

Here's version 2 of MySchema.  Nobody on the receiving end cares about
all that OptionalStuff, so I removed it.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:foo="http://www.someURL.org/MySchema"
targetNamespace="http://www.someURL.org/MySchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xs:element name="MySchema">
     <xs:complexType>
        <xs:sequence>
           <xs:element name="Stuff"/>
           <xs:element name="MoreStuff"/>
        </xs:sequence>
     </xs:complexType>
  </xs:element>
</xs:schema>

The following instance document, produced by a system conforming to
version 1 of MySchema, and dutifully including OptionalStuff, will fail
validation under version 2 of MySchema.  The systems receiving the
instance document (assuming they're using validation) will fail to
process the document, even though the missing element is one they don't
use.

<?xml version="1.0" encoding="UTF-8"?>
<MySchema xmlns="http://www.someURL.org/MySchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.someURL.org/MySchema.xsd">
  <Stuff/>
  <OptionalStuff/>
  <MoreStuff/>
</MySchema>

You can easily reverse this example, by adding a new required element in
version 3 of MySchema, as shown below.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:foo="http://www.someURL.org/MySchema"
targetNamespace="http://www.someURL.org/MySchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xs:element name="MySchema">
     <xs:complexType>
        <xs:sequence>
           <xs:element name="Stuff"/>
           <xs:element name="MoreStuff"/>
           <xs:element name="StillMoreStuff"/>
        </xs:sequence>
     </xs:complexType>
  </xs:element>
</xs:schema>

Under version 3 of MySchema, the following instance document, which is
compatible with both version 1 and version 2 of MySchema, will fail
validation.

<?xml version="1.0" encoding="UTF-8"?>
<MySchema xmlns="http://www.someURL.org/MySchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.someURL.org/MySchema.xsd">
  <Stuff/>
  <MoreStuff/>
</MySchema>

What we need is a definition of compatibility that is expressed solely
in terms of the instance documents and the schema themselves. How about
these definitions?
"A given version of a schema is backward compatible with a prior version
of the same schema if any document created under the prior version of
the schema is still valid under the later version, assuming all nodes in
the instance document not present in the later version of the schema are
ignored."

"A given version of a schema is forward compatible with a later version
of the same schema when any document valid under the later version of
the schema is also valid under the prior version, assuming all nodes in
the instance document not present in the prior version of the schema are
ignored".

Note that it still possible to break compatibility, as illustrated in
the difference between version 2 and version 3 of MySchema.  By adding a
new required element, I guarantee that documents created in accordance
with version 1 and 2 of MySchema will fail validation against version 3.

Bill

Received on Friday, 24 February 2006 15:38:38 UTC