W3C home > Mailing lists > Public > xmlschema-dev@w3.org > October 2004

Re: 3rd try on versioning question

From: <noah_mendelsohn@us.ibm.com>
Date: Mon, 18 Oct 2004 18:12:25 -0400
To: dean@xsoftware.biz
Cc: xmlschema-dev@w3.org
Message-ID: <OFE04B1F5D.3572565C-ON85256F31.0045803B@lotus.com>

Dean writes:

>> I am looking for an industry standard on how to do 
>> versioning and extensibility.

The short answer to your query is:  the challenges of evolving 
vocabularies, either to support new features or to fix bugs, are 
understood to be an important challenge for the XML community in general 
and for XML schema in particular.  Both the schema workgroup and the W3C 
Technical Architecture Group have been investigating requirements, use 
cases and possible implementation mechanisms.  Versioning is also known to 
be an extermely challenging issue, not just for XML but in general. 

I would put your example into the broad class of:  "you are willing to put 
explicit version control information into the instance documents" use 
case.   It seems that this is only suitable for some users and in any case 
there are a variety of means that have been proposed for doing it.  Other 
approaches to controlling versioning from within the instance include 
using xsi:type, substitution groups (altnerate element names), etc.  As an 
example of a use case where I would claim this approach does not work, 
imagine a bug fix to a version of HTML.  Do we really expect HTML users to 
say:

        <html2:img super="html1">...<html2:img>

just to get some correction to the interpretation of the <img> tag?  So as 
I say, there are many differing use cases and requirements.  The schema WG 
in particular is working hard to identify 80/20 points for which modest 
changes to XML schema mechanisms will provide compelling value to a large 
number of users.

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








dean@xsoftware.biz
Sent by: xmlschema-dev-request@w3.org
10/16/2004 02:28 PM

 
        To:     xmlschema-dev@w3.org
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        3rd try on versioning question



I have asked a few times, and have not quite given up just yet.  I am
looking for an industry standard on how to do versioning and
extensibility.  It would be great if there was a standard way of doing
this.  I have used some standards that kind of messed up and we couldn't
extend it.

Something new in the xsd like below would help greatly in this area.....

Say you have xml
<CarVersion1>?<CarVersion1>
The next standard comes out and is
<CarVersion2 super="CarVersion1">?.<CarVersion2>  where they have added
subelements to the standard
And another
<CarVersion3 super="CarVersion2:CarVersion1">?.<CarVersion3>
Last one decides it is not compatible with version 1 anymore(only stays
compatible with last 2 releases
<CarVersion4 super="CarVersion3:CarVersion2">?.<CarVersion4>

Typically you only stay compatible 3 releases back(well, if you can even
do that as without some strategy like above in w3c specs, it is really
hard to do such a think).

Now, if I have a server that sends back CarVersion3 events, a client who
only knows version 1 can understand the event as he will ignore all the
fields in the sort of a subclass kind of thing.

Instead, all companies I know of implement a version 3 spec and send back
version 1, version 2, version 3 events resulting in 3 times the code. 
This is not pretty.  Is there a cleaner way I am not aware of?

This also solves the extensibility problem allowing companyX to create
<CompanyXCar super="CarVersion2:CarVersion1">...

Notice that the parser can look at CompanyXCar and if it only knows the
version 1 spec, will automatically know that this is CarVersion1.  The
super is a list of elements that this xml packet also happens to be.

This also helps with SOAP alot because objects can be subclassed and I can
passback a subclass which will marshal to CarVersion3 instead of the
superclass CarVersion 1.  unmarshalling back will depend on the version of
the client.
thanks for any info,
dean
Received on Monday, 18 October 2004 22:15:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:15:11 UTC