[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: XML Schema Versioning


xml versioning
Title: XML Schema Standards
Your approach is fine and reasonably consistent with how others approach
that task.  As to versioning:
 
1. Visit http://www.xfront.com.   Review the best practices there.   Note that there is
also an XML Schema for Units of Measure there.   You may want to contribute
to that.
 
2.   Google for XML Versioning Version.  You will find that there has been 
considerable discussion of that topic for a number of years.   There isn't 
a one size fits all solution.
 
len 

From: Barwell Jonathan [mailto:Jonathan.Barwell@a...]

Our organisation is just getting up to speed with XML and we are currently trying to put some standards together.  As part of this initiative I am trying to come up with a strategy for versioning of XML Schemas.  My current plan is that we develop 3 types of schemas 1) Core Component Library - A library of commonly used simple types and attributes that define the structure of elements, e.g. "string20Type" defines a string with a maximum length of 20 characters etc. 2) Business Component Library - A library of simple and complex types that are more specific to our individual business requirements, e.g. UnitOfMeasureType that defines an enumerated list of Units of Measure, uses structures defined in the Core Component Library.  3) Application/Service specific schema - Schema specifically related to the application or service to support a business process, reuses structures from the Core Component Library and the Business Component Library.

 

The reason I have structured our schemas like this is to try and get reuse out of standard elements and to avoid semantic translations between applications that are reusing the same information.

 

However, this is causing me a big headache trying to come up with a versioning strategy.  It is likely that our schemas will form the basis of Web Services and therefore will need to be both forward and backward compatible.  Obviously adding new types to my library will not be a problem but if the business changes the validation rules for a specific type, e.g. changes a pattern of a string from [A-Z]{3}\d{1,4} to [A-Z]{4}\d{1,4}, then this has broken my compatibility. 

 

I want the schemas to do most of the validation therefore "version" attribute in the <schema> tag is insufficient.  Creating my own <simpleType> of "SchemaVersion" is also insufficient as I am referencing 3 types of schema and my application schema needs to be valid against the library schemas.  Namespacing does provide me with the validation levels I am looking for but then the schemaLocation will also need some level of versioning by using file name versioning or directory versioning structure.

 

Does anyone have any experience of version controlling their schemas, UBL has included versioning but to me their solution doesn't really seem to hang together tightly enough.

 

I would be grateful for any feedback from your experiences.


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.