Re: [xml-dev] Backward and forward compatible schemas ... Relax NG --> Y

["Fraser Goffin" <goffinf@googlemail.com>]

> 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.

 

On 27/08/07, Rick Jelliffe <rjelliffe@allette.com.au> wrote:

On Thu, 2007-08-23 at 22:33 -0700, Dave Orchard wrote:
> The blanket statement that XML schema 1.0 does not support forwards and backwards compatibility is incorrect.  Using an "Extension"
> or "Sentinel" element, one can get around XSD 1.0 UPA constraints at the cost of extra markup in instances.  This is shown in the
> W3C TAG Versioning Finding(editors draft) XML and Schema doc, section 7.4 http://www.w3.org/2001/tag/doc/versioning-xml#versionid3
> and in the section 4 "Version Strategy" of an XML.com article explaining forwards compatibility using XSD 1.0
> (http://www.xml.com/pub/a/2004/10/27/extend.html?page=4)

I think Dave is replacing one blanket statement with another. To say "it
supports it in a particular case" is no rebuttal to people saying "it
doesn't support it in every case, by which I mean 'in my case'."

What people complain about with XML Schemas 1.0 is having to adjust the
base schema when they want to just be able to adjust the derived
schemas. (That you have to add wildcards or <other> elements willy nilly
is as old as the hills, and no advance on parameter entities or
<redefine>.)

However, the whole basis of XML Schemas is namespaces and modularity,
and that means adopting standard or industry vocabularies which almost
universally have not been written to be open. People are really loath to
rewrite standard or industry vocabularies.

That being said, the new features in XSD 1.1 for openness look a step in
the right direction for capabilities, except for adding to the monolith
and thereby being a step in the wrong direction complexity-wise.

Cheers
Rick




_______________________________________________________________________

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@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php