I've been working pretty hard over the past few years to help improve extensibilty and versioning in XML and Web services, and one of the key pieces of that is use of XML Schema. I was quite happy quite some time ago when the XML Schema WG decided that they would improve extensibility and versioning support in Schema 1.1. I'd heard lots of discussion about "low priority wildcards" being the prefered solution.
Lo, the Schema 1.1 Working Drafts got published a few days ago. And they verily said that versioning was important. But to my surprise, the text that was in the draft is on issue 36i, which points to a w3c member only landscape summary email. Now this email is very good at describing the landscape. But I'm sad that the first version(!) of Schema 1.1 doesn't contain concrete syntax.
I was really hoping to be able to write a blog entry that said "hey look, here's the cool things that you can do with schema 1.1 that you couldn't do with with schema 1.0". But alas, I'll have to wait.
I trolled about through the emails on the topic, and I can see that they ran into some pretty big issues. They've spent a lot of time on composition of schemas. I'd run into the problems of schema composition and extensibility when I pointed out the problems of wildcards and type extension, but I hadn't thought of substitution groups.
It's clear they have to figure out composition and wildcards before they can really roll out a new model for wildcards and element declarations.
Why is this important? So that you don't have to do the Extension element technique that I advocated or the delimiter technique that Dare advocates.
I guess we won't get a default extensibility model either. But I guess half the solution is better than none.
Another aspect of extensibility/versioning that Schema 1.1 mentions, but doesn't provide concrete changes for, is the ability to specify exclusion of multiple namespaces. I hope this makes it in as well, and even with an expression for including or excluding namespace names - as I mentioned in the "variable namespace name" section.
The advantage of this approach is that we could define a granularity of where 3rd party extensions can happen versus owners of namespaces. An owner of a namespace may potentially own many namespaces. For example, I own the pacificspirit.com domain. I may want to allow third parties (not http://www.pacificspirit.com) to put there extensions only at the end of my type, and I want to allow myself to put extensions in between my elements in a type, ie targetnamespace="http://www.pacificspirit.com/*".
And lastly, I see that Schema has the ever present versioning problem: Do they use a new namespace name, re-use the old namespace name, or use multiple namespace names for their "extensions/versions". I wrote up some material about extensibility versus versioning towards the end of http://www.pacificspirit.com/Authoring/Compatibility/ProvidingCompatibleSchemaEvolution.html.
It would be very useful if we can come up with more material on what are the trade-offs between these various approaches, so that a namespace owner can have more information at their disposal when making a choice. Maybe like a TAG finding?