Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: XSD versioning ...

From: Dragon Fly <dragon-fly999@-------.--->
To: Pete Cordell <petexmldev@---------.--->, <xmlschema-dev@--.--->
Date: 7/11/2008 12:53:00 PM
Thank you all for the information.  I'll have to think about it.

> From: petexmldev@c...> To: dragon-fly999@h...=3B xmlschem=
a-dev@w...> Date: Fri=2C 11 Jul 2008 16:23:12 +0100> Subject: Re: XSD ver=
sioning ...> > > You can design your XSD schema so that it accommodates ver=
sioning. This is > mainly done using xs:any=2C but=2C especially in XSD 1.0=
=2C there are gotchas > involved in this. There's a good article on this at=
:> > http://www.xml.com/pub/a/2004/10/27/extend.html> > The story for XSD 1=
.1 should hopefully be a lot better.> > One thing such versioning strategie=
s miss is the ability to declare that > certain version 2 concepts are requ=
ired to be understood by a parser=2C > otherwise the message should be reje=
cted in some way. This procedure has to > be defined when version 1 is spec=
ified. The method I like best is using an > attribute called something like=
 "Requires" in the top level element which > contains a number of tokens th=
at the receiving parser must understand in > order to fully understand the =
message. This to me keeps all the > compatibility assessment in one place a=
nd allows for an easy go/no go > decision quite early.> > Just as an exampl=
e=2C it might look like:> > <MySchema Requires="foo bar">...> > That's sa=
id=2C your versioning strategy does depend on things like whether you > hav=
e one way or two way communication=2C or there's an archival aspect to it >=
 etc.> > HTH=2C> > Pete Cordell> Codalogic> For XML C++ data binding visit =
http://www.codalogic.com/lmx/> > ----- Original Message ----- > From: "Drag=
on Fly" <dragon-fly999@h...>> To: <xmlschema-dev@w...>> Sent: Frid=
ay=2C July 11=2C 2008 3:24 PM> Subject: XSD versioning ...> > > What is the=
 best way to handle XSD versioning? Let's say I have the > following scenar=
io ...> > - Version 1 of the XSD is given to a customer.> - The customer wr=
ites a parsing program (that performs validation against > V1).> > 3 months=
 later ...> > - A new element is added to version 2 of the XSD.> - The new =
XML files sent to the customer have the new element.> - The new XML files f=
ail validations because version 1 of the XSD does not > have the new elemen=
t.> > Is there anything that I can do to plan for this? Thank you.> > _____=
____________________________________________________________> It=92s a talk=
athon =96 but it=92s not just talk.> http://www.imtalkathon.com/?source=E=
ML_WLH_Talkathon_JustTalk > > > 
_________________________________________________________________
Need to know now? Get instant answers with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM=
_WL_messenger_072008=


transparent
Print
Mail
Digg
delicious
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