RE: XML Schema Versioning Use Cases

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: XML Schema Versioning Use Cases

David Ezell

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:[hidden email]
[2] http://lists.w3.org/Archives/Public/public-xml-versioning/
[3] mailto:[hidden email]

>"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:[hidden email]]
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





Reply | Threaded
Open this post in threaded view
|

Definition of forward/backward compatibility (was: XML Schema Versioning Use Cases)

Hoylen Sue

Bill,

Thank you for your comments.

The "XML Schema Versioning Use Cases document"
http://www.w3.org/XML/2005/xsd-versioning-use-cases/2006-01-31.html#p57
says:
>>"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."

Bill Wade says:
> 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."

Two comments on this definition:

Firstly, validation is not the only purpose of XML Schemas.
This is why the definition does not rely on validity, but on
the mouthful "can be processed by an application that
handles the new schema".

Secondly, "assuming all nodes in the instance document
not present in the later version of the schema are ignored"
is defining a mechanism to achieve backward compatibility
rather than a definition of it.


However, I do like the suggestion that we claify what
exactly is classified as being "backward compatible" -- in
this case it is the schemas.  This is because in the XSD use
case, there will be schema processors, schemas, and instances.

The current definitions refers to "old schema" and "new
schema" -- characterizations which do not apply to some of
the versioning use cases.

Hoylen
--
____________________________________________________________
[hidden email]                     http://www.hoylen.com/


Reply | Threaded
Open this post in threaded view
|

Re: Definition of forward/backward compatibility (was: XML Schema Versioning Use Cases)

noah_mendelsohn

I think there are many potentially useful classifications of abstraction,
some involving only the schema and instance, and some involving more parts
of the stack or different parts of the stack.  Overall, though, I tend to
agree with Hoylen:  the ultimate goal in most cases is either to get two
applications to work together, in spite of their somewhat differing
expectations for the content of documents they share, or else to get those
applications to correctly conclude that working together is not in fact
practical.  Schemas and schema processing are tools that may be useful in
achieving such interoperation, or in making a decision not to proceed.
Bill is right, I think, in implying that our specific goal will be to
define the use of schemas in such scenarios, but to design the schema
mechanisms well, we will need to consider the overall needs and processing
models of the applications.

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Hoylen Sue <[hidden email]>
Sent by: [hidden email]
03/04/2006 03:12 AM
 
        To:     "Wade, William (Bill)" <[hidden email]>
        cc:     [hidden email], (bcc: Noah
Mendelsohn/Cambridge/IBM)
        Subject:        Definition of forward/backward compatibility (was:
XML Schema  Versioning Use Cases)



Bill,

Thank you for your comments.

The "XML Schema Versioning Use Cases document"
http://www.w3.org/XML/2005/xsd-versioning-use-cases/2006-01-31.html#p57
says:
>>"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."

Bill Wade says:
> 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."

Two comments on this definition:

Firstly, validation is not the only purpose of XML Schemas.
This is why the definition does not rely on validity, but on
the mouthful "can be processed by an application that
handles the new schema".

Secondly, "assuming all nodes in the instance document
not present in the later version of the schema are ignored"
is defining a mechanism to achieve backward compatibility
rather than a definition of it.


However, I do like the suggestion that we claify what
exactly is classified as being "backward compatible" -- in
this case it is the schemas.  This is because in the XSD use
case, there will be schema processors, schemas, and instances.

The current definitions refers to "old schema" and "new
schema" -- characterizations which do not apply to some of
the versioning use cases.

Hoylen
--
____________________________________________________________
[hidden email]                     http://www.hoylen.com/





Reply | Threaded
Open this post in threaded view
|

Re: Definition of forward/backward compatibility (was: XML Schema Versioning Use Cases)

noah_mendelsohn

I wrote:

> I think there are many potentially useful classifications of abstraction

I hope it was clear from the context that I meant:

> I think there are many potentially useful classifications of
compatibility

The downsides of typing on an airplane where there is so little space you
can't see your screen well enough to proof read (and probably being jet
lagged when I wrote it).  Sorry for any confusion.  I hope the rest of the
response makes sense.  Thank you.

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------