W3C home > Mailing lists > Public > public-xsd-databinding@w3.org > February 2006

RE: ISSUE-20: Extension of collections

From: Erik Johnson <erikj@epicor.com>
Date: Wed, 22 Feb 2006 09:05:37 -0800
Message-ID: <BF9C5B9528B9C246BC41C7B988C49C8701A468EC@slate.americas.epicor.net>
To: <public-xsd-databinding@w3.org>

I don't know if I have a great solution here, but it seems like
extensibility and versioning are being muddled.  By versioning, I mean
having some definition of backward and/or forward compatibility between
two or more schema types.  The same compatibility would have to exist
between the corresponding class types.  Since most languages do not have
specific mechanics for versioning, is it even possible to project a
versioning scheme from a schema set to a language in a meaningful way?  

I agree that it would be very good to specify best practices for schema
evolution (how to maintain backward compatibility, when to change the
namespace name, etc.) and give serializer guidance about how to
process/ignore "extra" nodes and when to give up trying to match the
payload with class members.

Also, I don't see a problem with using xs:any and mapping that to a
generic type (like "object").  But the "namespace" attribute is a
problem because (in most languages) there is no way to constrain a class
member to be any type within a certain namespace.  Should the guidance
avoid using namespace attribute values other than "##any"?

- Erik

-----Original Message-----
From: public-xsd-databinding-request@w3.org
[mailto:public-xsd-databinding-request@w3.org] On Behalf Of Pete Cordell
Sent: Wednesday, February 22, 2006 1:52 AM
To: paul.downey@bt.com; edday@obj-sys.com; public-xsd-databinding@w3.org
Subject: Re: ISSUE-20: Extension of collections


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 17:05:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:20:36 GMT