Cart
[Home] [By Thread] [By Date] [Recent Entries]
> 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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
