Dean,

I've been scratching my head on these topics as well for some time.  =
While
my research is really informal, a survey I did some time ago revealed a =
few
things.  First, there is no "standard" way to version and extend.  I =
agree
that this would be great, but the fact is different groups do different
things.  Second, the most common way to add extensibility at schema =
design
time is the use of "xs:any" elements sprinkled around your data.

What you are doing with CarVersion1, CarVersion2, ... is to version =
every
data node.  Indeed, discussions on the topic of extensibility have lead =
to
this idea within HR-XML.  However the complexities of versioning at the
element level more than outweighed the benefits (simplest method usually
wins).  So we use xs:any.  And to take it into the "best practices" =
arena,
we do advocate good design principles such as creating global types for
elements so as to make reuse and extensibility easier.  

I'd be willing to contribute some time on an article on the topic if =
there
are others who would want to collaborate.  Sort of a methods-tried and
lessons-learned type of article.  I know there are a few out there, but =
we
can always use another one in this area.

Cheers,

Paul Kiel
HR-XML Consortium




-----Original Message-----
From: xmlschema-dev-request@w... [mailto:xmlschema-dev-request@w...] =
On
Behalf Of dean@x...
Sent: Saturday, October 16, 2004 1:29 PM
To: xmlschema-dev@w...
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








From Burak.Emir@e... Mon Oct 18 13:50:11 2004
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.34)
	id 1