Re: XML Schemas: Best Practices ? Versioning

[Ronald Bourret <rpbourret@rpbourret.com>]

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