Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: XSD versioning ...

From: "G. Ken Holman" <gkholman@----------------.--->
To: <xmlschema-dev@--.--->
Date: 7/11/2008 6:50:00 AM
At 2008-07-11 10:24 -0400, Dragon Fly wrote:
>What is the best way to handle XSD versioning? 
>Let's say I have the following scenario ...
>
>- Version 1 of the XSD is given to a customer.
>- The customer writes 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 fail validations because 
>version 1 of the XSD does not have the new element.
>
>Is there anything that I can do to plan for this? Thank you.

The Universal Business Language (UBL) Technical 
Committee is anticipating this very situation as 
UBL 2.0 is rolled out around the world and 2.1, 
2.2, 2.x, 2.y get developed to meet new requirements of users.

For backward compatibility, all new constructs 
defined in revised models are optional so that an 
old instance will still conform to any new document model.

For forward compatibility, a proposed processing 
model for a version 2.x system filters out any 
unknown constructs not defined by 2.x so that the 
validation can happen on that subset of 
recognized constructs.  So when 2.y is greater 
than 2.x, that 2.x subset of 2.y is processed by 
the application.  The processing model includes a 
signal of whether or not any unrecognized 
constructs were removed (which is not always the 
case, a 2.y-labeled instance might have only 2.y constructs in it).

The UBL naming and design rules requires every 
UBL document type to have room for the instance 
to indicate the version being used, so a 2.x 
system will be told the sender used a 2.y 
instance.  But, again, if there were no 
violations of 2.x constraints, it is moot that the instance is of version=
 2.y.

Check out the versioning conference in advance of 
Balisage this summer in Montr=E9al:

   http://www.balisage.net/Versioning/index.html
   http://www.balisage.net/

There are many presentations (including mine on 
UBL) at that symposium.  The proceedings will include a full copy of my=
 paper.

I hope this helps.

. . . . . . . . . . . . . . Ken

--
Upcoming XSLT/XSL-FO hands-on courses:      Wellington, NZ 2009-01
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman@C...
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/x/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/x/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal


From petexmldev@c... Fri Jul 11 15:24:01 2008
Received: from maggie.w3.org ([193.51.208.68])
	b


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