RE: LC124

Pete,

I don't quite follow your example. The additional values added in the v2
schema are mandatory, so the schema would fail to validate a v1 message and wouldn't
be backwards compatible with a client sending messages constructed using the 
original schema.

So the usual case in this kind of evolution is that the additional elements are marked 
with minOccurs="0", and putting minOccurs="0" ahead of the "slurping vortex of the
greedy xs:any wildcard"* violates UPA.

This issue has been outlined in a number of papers, articles and conference 
presentations, including one from our own Dave Orchard:
http://www.xml.com/pub/a/2003/12/03/versioning.html

by Dare Obsanjo, who offered a 'wrapper pattern' work-round:
http://www.xml.com/pub/a/2004/07/21/design.html

and I too dined out on this problem with a presentation:
http://whatfettle.com/2004/09/XMLOpen/

Even with Dare's suggestion, if all that was required was to add this magic 
to the end of each and every sequence, and "some tool was generating the
schemas" or those tools and everyone, in particular publishers of schemas
for vertical standards, used this incantation already, then I'd agree,
there wouldn't be an issue!

LC124 isn't a request for syntactic sugar. Rather, that it isn't possible to write 
compatible schemas to describe the simple evolution outlined by your example.

Paul

* more or less how Doug Purdy described it at the Schema Workshop



-----Original Message-----
From:	Pete Hendry [mailto:peter.hendry@capeclear.com]
Sent:	Fri 7/8/2005 10:03 AM
To:	Downey,PS,Paul,CXMA C
Cc:	www-ws-desc@w3.org
Subject:	Re: LC124

Ok. Another question. Why can't standard schema extensibility be used if a schema designer wants to be able to add elements in future?

<complexType name="X">
    <sequence>
       <element name="name" type="string"/>
       <any namespace="##targetNamespace" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
    <anyAttribute namespace="##targetNamespace" processContents="lax"/>
</complexType>

and then the new version of the type define other elements explicitely

<complexType name="X">
    <sequence>
       <element name="name" type="string"/>
       <element name="id" type="string"/>
       <element name="age" type="int"/>
       <any namespace="##targetNamespace" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
    <anyAttribute namespace="##targetNamespace" processContents="lax"/>
</complexType>

Then if a client using the original schema gets back a message containing

    <...>
       <name>Pete</name>
       <id>1234</id>
       <age>21</age>
    </...>

it will at least still validate against the schema.

It is obviously a bit of work to add this to each type but the expectation is that some tool is generating the schema so this is not a problem.

Pete

Received on Monday, 11 July 2005 09:20:36 UTC