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