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

Re: XML Schemas: Best Practices ? Versioning

  • From: Ronald Bourret <rpbourret@r...>
  • To: Milton Taylor <mctaylor@i...>
  • Date: Wed, 05 Sep 2001 22:13:55 -0700

backward compatibility xml schema
Milton Taylor wrote:
> In my view applications shouldn't necessarily reject a new document version
> in approach #1. They just would not be able to 'process' the unrecognised
> elements.
> 
> ** This is the key issue in many circumstances: the need to enhance the
> schema with new elements on the generation side, without having to
> simultaneously upgrade the software at the receiving side, so as not to
> 'break' the receiver from processing the existing data elements.

Agreed. I think the key words here are "necessarily reject". It's up to
the application to decide what's right.

(Note that in cases of backward compatibility, this is easy -- the
application says it works against values x, y, and z of the version
attribute. In cases of forward compatibility, this doesn't really seem
possible. How can an application that accepts, for example, version
"1.0" also know it can accept version "1.73"?)

> Perhaps the easiest way to deal with this is to ensure that documents at
> version 2 are 'valid' with schema version 1. This can only be achieved by
> having some optional 'any' elements at various places in schema 1. In his
> previous best practices paper on this topic, Roger C. was advocating this
> approach, but unfortunately there are severe limits to how far you go with
> this, especially to avoid technically invalid schemas. (Due to ambiguities).
> 
> An example: in an element sequence model, schema version 1 could have an
> optional unbounded 'any' element as the last in the sequence.This way, a new
> element can be added in the version 2 schema just prior to the 'any'
> element, and then version 2 docs are still valid with version 1 schema. But
> it's more difficult / probably illegal to introduce the optional 'any'
> elsewhere in the sequence, esp if the preceeding and succeeding elements are
> from the same namespace and are optional as well.

Workable, but yech. any would allow all sorts of
guaranteed-to-be-illegal stuff, so I'm not convinced it's a good idea.
Another way to do this would be to:

1) Write the version 1.0 application so it ignores any elements it
doesn't understand,

2) Validate against the version 2 schema, and

3) Run a quick filter (e.g. SAX) to change the version attribute from
2.0 to 1.0 just before processing version 2.0 files.

Granted, this does "break" version 1.0 applications, but only to the
extent of placing a filter in front of them. As a conscious decision,
this isn't necessarily a bad thing.

> If you can't make a backward compatible change to the schema, then you drop
> over to approach #2?

Probably so.

-- 
Ronald Bourret
XML, Databases, and Schemas
http://www.rpbourret.com
Speaker, Geek Cruises' XML Excursion '02

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.