Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


3rd try on versioning question

From: dean@---------.---
To: xmlschema-dev@--.---
Date: 10/16/2004 4:29:00 AM
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>=85<CarVersion1>
The next standard comes out and is
<CarVersion2 super==94CarVersion1=94>=85.<CarVersion2>  where they have=
 added
subelements to the standard
And another
<CarVersion3 super==94CarVersion2:CarVersion1=94>=85.<CarVersion3>
Last one decides it is not compatible with version 1 anymore(only stays
compatible with last 2 releases
<CarVersion4 super==94CarVersion3:CarVersion2=94>=85.<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 ca=
n
passback a subclass which will marshal to CarVersion3 instead of the
superclass CarVersion 1.  unmarshalling back will depend on the version o=
f
the client.
thanks for any info,
dean





From incivinci@g... Sun Oct 17 07:47:59 2004
Received: from lisa.w3.org ([128.30.


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent