RE: Backward and forward compatible schemas ... Relax NG --> Y

> People are really loath to rewrite standard or industry vocabularies.
 

On a practical level that's true, but I don't see this as much of a rebuttal either, unless you mean that neither the Sentinel approach or XSD 1.1 provide a sufficiently compelling case to make the 'pain' of change worthwhile (at least for now).

And, if the reason why people identify the need for managing change to their controlled vocabularies is significant, for example, they need to implement a versioning policy, then, the pain of the status-quo might also be untenable, at least in the medium to longer term.

I work in a industry that *does* provide a canonical data model expressed as XML schema (and more abstractly). As you point out, this vocabulary like many others I have come across, has *no* mechanism for managing change other than that all changes are effectively new requirements and represent breaking changes that either need to be implemented in 'big bang' style or mean that all users of the vocabulary potentially need to support multiple concurrent versions. 'Big bang' is clearly a non starter in most cases where more than a trivial number of trading partners are involved, and even then its usually pretty difficult to synchronise. Multiple concurrent version support *will* IMO be necessary for some, but shouldn't be a requirement for all.

The most obvious result of this deficiency is that, rather than encouraging wide-spread industry adoption of a market standard data (and process) model, users tend eventually to drift away from since it cannot support the necessary and often frequent change in the business process model (usually as soon as version 1.0 is delivered and a change request happens along !). As soon as it becomes a choice between adherence to a data standard and constraining the business opportunities for individual or between communities of trading partners, there can only be one winner. Of course you *could* argue about whether an industry standard is really worth the effort and, if it is 'hobbled' by these sort of constraints, then maybe not. This is another thread perhaps, so I will just say that 'in my case' I believe that there *are* advantages that are worth trying for, and pick it up later if others want to discuss the pros and cons.

So whilst re-writing existing vocabularies to support extensibility (particularly for private extensions) can (initially) be painful, the alternative of *do nothing* is IMHO equally unsavoury.

Fraser.