> XSD 1.1 allows you to use conditional type assignment switched on the
> version number, so you don't need two separate schemas, it can all go in
> one.

ah of course, that will makes things easier, removing the need to
explicitly version the xsd somehow and extract the version from the
xml to use the appropriate xsd etc...

> But the essential point is that this is not primarily an issue of schema or
> vocabulary design. It's primarily an issue of application design. If
> applications aren't future-proof, nothing you do in a schema will keep them
> working when the data changes.

hmm managing application change is easy enough I think, it's managing
xml change that there doesn't seem to be an established process to
follow (and the more places you look for inspiration, the more
variations you find...)

So, is the suggested best practice:

- Use the same namespace forever, don't change it (so dates or
versions in the namespace might not be suitable)
- Use a version attribute on the root element
- Use a single xsd, switch types on the the version number (so don't
put a version in the filename) ... in which case, if its unlikely to
change, should you embed the schemaLocation in the xml?

when the xml needs to change:

- Increment the version number in the xml appropriately
- Adjust the xsd (the version of this should match the xml version,
not sure where that would be defined in the xsd...)
- Adjust the processing code

I can't see many problems with doing it this way... anything else to
add or change?




thanks
-- 
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php