- 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