Re: 3rd try on versioning question

wow, alot of great responses this time.  I really like the counter on the
html example.  That is really good.  I will have to think more about that.
It really depends on the way html authoring is done these days.  I guess we
are not to the point where it is primarily done with tools yet especially
when it comes to jsp's.  Most developers are still typing these up without
using any tools.  I have thought about this problem for a while, and have
thought of a few solutions of which seem to always have upsides and
downsides like the one you mention.
    Is there any articles referencing what the w3c is talking about doing on
solving the problem?  The only thing I have read from the TAG was a short
paragraph in a TAG document which really didn't help in showing me what was
being discussed(just out of my curiosity).  I am extremly curious what the
whole SOAP community is going to do as more and more web services pop up
that use the Document literal encoding(which basically just uses xsd's).
    I guess my real question is whether there is a document with the list of
use cases????  I would very much like to see that.
thanks,
dean


----- Original Message ----- 
From: <noah_mendelsohn@us.ibm.com>
To: <dean@xsoftware.biz>
Cc: <xmlschema-dev@w3.org>
Sent: Monday, October 18, 2004 4:12 PM
Subject: Re: 3rd try on versioning question


>
> 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 Wednesday, 20 October 2004 03:49:41 UTC