XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] Backward and forward compatible schemas ... Relax NG --> Yes ... XML Schema --> No

The problem is belief in *status quo*.

 

I am amazed it took this long to notice.   Perturbations at the lower levels (b2b transactions) are the source for most changes in a system be they evolution or devolution.   Belief in top down control systems for cybernetic evolution is a well-known superstition.    Bottom up cascades across tiers of messaging are the most common source of system failures.   The trick is to isolate functional/operational regimes, not to insist that they are one very large system.   This means that checks are run often (validation is the norm not the exception) to catch small changes as they occur.  Don't fight the environment. 

 

Nor big bangs; enable frequent little ones.

 

len

 

-----Original Message-----
From: Fraser Goffin [mailto:goffinf@googlemail.com]
Sent: Monday, August 27, 2007 3:46 AM
To: xml-dev@lists.xml.org
Subject: Re: [xml-dev] Backward and forward compatible schemas ... Relax NG --> Yes ... XML Schema --> No

 

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

 

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS