- From: Pete Cordell <petexmldev@tech-know-ware.com>
- Date: Wed, 22 Feb 2006 09:51:56 -0000
- To: <paul.downey@bt.com>, <edday@obj-sys.com>, <public-xsd-databinding@w3.org>
Hi Paul,
To answer b) first, I believe multiply versioned instances ends up as the
staircase you suggest, e.g.:
<person> <!-- Version 1 -->
<firstName>Ted</firstName>
<lastName>Glenn</lastName>
<extension> <!-- Version 2 -->
<job>Inventor</job>
<extension> <!-- Version 3 -->
<address>Greendale</address>
</extension>
</extension>
</person>
I agree this is all very ugly and unintuitive, but in many respects I think
this makes it even more important to mention. As we all know, versioning is
one of the major weaknesses of XSD, and if people are investing major
resources (perhaps whole business strategies) on it it seems almost
negligent for experts not to mention it!
As I've never worked on something that has never been versioned, and I can't
see how to allow versioning without using xs:any and friends, my feeling is
that it's necessary to bite the bullet on this one and include this
versioning strategy, xs:any and all. This is a case where tools really have
to be up to the job.
(If you really, really, really didn't want to address versioning, then you
could take the line that versioning is a separate issue, and should be
addressed elsewhere. In that case IMHO I would not only include a reference
to work discussing versioning, but also strong words that say by default
your schema won't be versionable, and a hairy example of how to make it
versionable so that the reader comes away with the message "What the heck!
I'd better look that up now!", rather than thinking "It can't be that bad,
I'll get around to it sometime.")
Pete.
----- Original Message -----
From: <paul.downey@bt.com>
To: <petexmldev@tech-know-ware.com>; <edday@obj-sys.com>;
<public-xsd-databinding@w3.org>
Sent: Wednesday, February 22, 2006 9:12 AM
Subject: RE: ISSUE-20: Extension of collections
Pete, Ed
Thanks for the comments!
I'm personally not comfortable with this pattern, given it's:
a) as you say, not 'intuitive'
b) has a restriction on how the 2nd, 3rd etc evolutions
may be made represented (i'm guessing you'd end up
with a staircase of nested <extension> elements.
However I'm keen to say 'something' for versioning!
I understand that at least two binding tools do make
use of it when generating Schema from code, including at
least one major tool developed by Microsoft.
//I wondered if anyone else had personal experiences of
such extension patterns with toolkits?//
However I also have personal experience with a tool from a well
known J2EE vendor who's service generator tool rejects the whole
WSDL at the first sign of an xs:any or xs:anyType inside a Schema!
My current inclination is to avoid Recommending patterns which
use xs:any or xs:anyType in our Basic specification, and move
this subject to the Advanced patterns document.
This would be a blow to my personal aims in promoting patterns
for versioning and evolving messages, but probably be a better
statement in the art of the possible with current databinding tools.
Paul
-----Original Message-----
From: public-xsd-databinding-request@w3.org on behalf of Pete Cordell
Sent: Wed 2/22/2006 7:57 AM
To: Ed Day; Databinding WG
Subject: Re: ISSUE-20: Extension of collections
Hi Ed,
As I understand it, you are right. The versioned type would become
(including documentation about the versioning):
<xs:complexType name="CustomerType">
<xs:sequence>
<xs:element name="firstName" type="xs:string" />
<xs:element name="lastName" type="xs:string" />
<xs:element name="extension">
<xs:complexType>
<xs:annotation><xs:documentation>
These members were added in version 2
</xs:documentation></xs:annotation>
<xs:sequence>
<xs:element name="MyV2Element" type="xs:string"/>
<xs:element name="extension"
type="tns:CustomerExtensionType"
minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
<xs:complexType name="CustomerExtensionType">
<xs:sequence>
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"
namespace="##targetNamespace"/>
</xs:sequence>
</xs:complexType>
Pete.
----- Original Message -----
From: "Ed Day" <edday@obj-sys.com>
To: "Databinding WG" <public-xsd-databinding@w3.org>
Sent: Tuesday, February 21, 2006 7:18 PM
Subject: Re: ISSUE-20: Extension of collections
>
> The problem with this approach is that it requires the user to embed the
> <extension> element within the instance being extended. This is not what
> happens in the real world. What happens is additional elements just show
> up.
>
> Also, what happens if the schema is extended a 2nd time? Do you have an
> extension in an extension? Or maybe the "extension" element should have
> some kind of version number on the end to track when an extension happened
> (<extension1>, <extension2>, etc.)?
>
> Regards,
>
> Ed Day
> Objective Systems, Inc.
> http://www.obj-sys.com
>
>
> ----- Original Message -----
> From: "Databinding Issue Tracker" <dean+cgi@w3.org>
> To: <public-xsd-databinding@w3.org>
> Sent: Tuesday, February 21, 2006 9:05 AM
> Subject: ISSUE-20: Extension of collections
>
>
>>
>>
>> ISSUE-20: Extension of collections
>>
>> http://www.w3.org/2005/06/tracker/databinding/issues/20
>>
>> Raised by: Paul Downey
>> On product: Basic
>>
>> The input document offers the following pattern for a collection
>> which is open to extension, thereby being useful when evolving
>> or extending a schema during versioning:
>>
>> """
>> <xs:complexType name="CustomerType">
>> <xs:sequence>
>> <xs:element name="firstName" type="xs:string" />
>> <xs:element name="lastName" type="xs:string" />
>> <xs:element name="extension" type="tns:CustomerExtensionType"
> minOccurs="0" />
>> </xs:sequence>
>> <xs:anyAttribute/>
>> </xs:complexType>
>>
>> <xs:complexType name="CustomerExtensionType">
>> <xs:sequence>
>> <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"
>> namespace="##targetNamespace"/>
>> </xs:sequence>
>> </xs:complexType>
>>
>> """
>>
>> How well is this pattern supported by tools - does it belong in
>> the Basic patterns document?
>>
>> Are there authoring issues with this pattern we should warn about?
>>
>>
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
http://www.tech-know-ware.com/lmx
(or http://www.xml2cpp.com)
=============================================
Received on Wednesday, 22 February 2006 09:52:24 UTC