OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XML Schemas: Best Practices ? Versioning

I pretty much agree with Michael. I think #1 is useful (and possibly
best practice) when all documents from the old version are valid in the
new version. This happens in a number of cases, such as when the only
changes are extending existing complexTypes with optional elements or a
new element is added to an existing substitution group.

One other thing that needs to be added to the discussion is that any
versioning system that requires changes to existing documents also
requires changes to existing applications. Note that applications are
robust under both #1 and #2. In the first case, they reject the new
document version; in the second case, they don't recognize the new

Applications are not robust under #3 and #4, since the application
receives no hint that the meaning of various element/attribute names has
changed. I would therefore say that #3 and #4 are not good practice.

Ronald Bourret
XML, Databases, and Schemas
Speaker, Geek Cruises' XML Excursion '02

> Michael Brennan wrote:
> I don't think 3 and 4 are reliable. #3 makes the incorrect assumption
> that "instance documents give the name and location of the associated
> schema". This is undoubtedly the prevalent case, but as sound entity
> resolution mechanisms gain more widespread use, I'm inclined to
> believe there will be less and less of this. You cannot assume a
> consuming application is relying upon the "schemaLocation" attribute
> (or even paying any attention to it). I think changing the target
> namespace is the only reliable approach.
> In spite of the complications it poses, I think #2 is the best
> practice. True, instance documents and schemas that include the
> relevant schema must change to reference the new version, but that is
> often a good thing. You don't want those references to
> indiscriminately change to reference a new schema without assurance
> that there are no incompatibility issues. Indeed, by changing the
> namespace, you can permit concurrent use of different versions of a
> schema, allowing users time to migrate to the new version as
> compatibility is assured.