[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Caution using XML Schema backward- or forward-compatibilit

• From: "Fraser Goffin" <goffinf@g...>
• To: "David Carver" <d_a_carver@y...>
• Date: Fri, 4 Jan 2008 12:54:36 +0000

I'd like to pick up the point about extensibility.

David [Carver] suggested that providing non vocabulary owners the
opportunity to add [unratified] data structures into a centrally
controlled standard can have undesirable outcomes (i.e. damage the
viability or benefit of using a standard).

I agree, it *can*, but I think we need to consider the motivation of
organisations find themselves in this position. First, most
particpants in a community standard are IMO motivated to *want* to
leverage that standard for B2B exchanges. They typically understand
that operating a private data standard for each and every trading
partner can be a costly exercise, so are more than happy for a
standards body to carry this load. So, the reason for needing a
private extension is very often not to subvert the standard, but to
address a (potentially temporal) inadequancy (typically related to the
speed with which that change can be agreed through whatever process
exists).

Speeding up the [fully consensual] process would definately help, but
isn't always the answer. Why, well agreement by committee nearly
always takes a while and absolutely requires all interested parties to
particpate. But, in the real world, the particpants have very
different priorities and apply their resources accordingly. In my
experience organisations will only committ resources to review and
debate change proposals when/if they care about them. So if you're
asking for a change to a schema that organisation A doesn't implement
today, they will very likely take a 'back seat'.

Of course the policy for the standards body may be that the absense of
comment implies tacit agreement. But nevertheless it puts them in a
difficult spot and one which in my exerience they prefer not to be in,
that is, a change goes through which they think organisation A will
probably object to when they get around to it, thus creating more
change churn and the potential for an important contributor breaking
away from the standard. So this slows things down ...

On the other hand allowing [controlled] extensibility is often a way
of encouraging use of the standard, and has the benefit that a private
extension may be incorporated into the main body of the standard at a
later point in time (when more of the participants *are* interested)
-  note [controlled] here means doing the extension work WITH some
involvement from the standards body so that they are aware of the type
of things that participants *are* interested in and which can
sometimes help those coming later who want to do something similar.

And let us not forget, an organisation explicitly chooses to use a
data standard and at any time can choose to 'go private', so IMO
disallowing extensibility isn't really a way of controlling
participant activity, indeed, that shouldn't be an aim of the
standards body and if it turns out that way, then more often than not
it will drive people away from using the standard (i.e. if the use of
a data standard interferes with a business operating model, the data
standard will be dropped).

Another reason for extensibility is to allow organisations to carry
application specific data around that is required for their individual
processing needs. An obvious example is 'enterprise keys', i.e. those
pieces of data that you need to
successfully update a row on your database. This is one IMO that the
central authority should support in the form of an opaque (i.e. that
it is only meaningful to the node which inserted it) extensibility
areas possibily with some constraints over size (e.g. a single element
as Base64 of a maxLength) and rules around it processing (i.e. always
return it if present, and always return it as/is).

Fraser.

On 03/01/2008, David Carver <d_a_carver@y...> wrote:
> noah_mendelsohn@u... wrote:
> > Actually, I'm not convinced that's always the reason.  In many cases, the
> > reason you want extensibility is that some core format or business
> > document is to be extensible in different ways by different organization.
> > So, an entire industry might agree on an extensible invoice or purchase
> > order format, with the understanding that individual organizations using
> > the document can add their own additional tracking fields and the like. In
> > such cases, it would be inappropriate to try and route all the private
> > extensions through a central authority, no matter how quick and responsive
> > that authority is.
> >
> Yes, standards organizations like OAGi and UBL fall into this category
> as they are going across verticals, so they include an extension
> mechanism here. But the problem with extension mechanisms in general is
> that it creates on off implementations, and if you are doing B2B
> scenarios and many trading partners with multiple implementations, it
> makes it counter productive.
>
> > One of the important dimensions to consider is that some XML languages
> > are, for good reasons, evolved completely centrally.  Others are evolved
> > by a limited number of organizations, sometimes in cooperation, but
> > sometimes in competition.  It's not at all unusual for one organization to
> > pick up a programming language, document format, etc., to change it,
> > perhaps in compatible ways or perhaps in other ways, and to promote the
> > use of its version(s) in competition with others that are out there.  This
> > certainly happened with HTML for quite awhile.  Finally, as mentioend
> > above, some languages are intended from the start for decentralized
> > enhancement or evolution.  In many cases, those languages prove to be some
> > of the most interesting and powerful for users.
> >
>
> All agreed, but again if we focus on B2B issues, and particular the
> compatiblity issues that existed and still exist with HTML, you have to
> use extensions wisely. Unfortunately, most instances from my experience
> when dealing with Industry specific schemas/grammars is that the reason
> for the one offs is because members have felt that their particular
> requirements couldn't be expressed in the their needed time frame. And
> it's been directly related back to the speed at which their requests are
> adopted.
>
>
>
> _______________________________________________________________________
>
> 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@l...
> subscribe: xml-dev-subscribe@l...
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>

• References:
  • RE: Caution using XML Schema backward- or forward-compatibilityas a versioning strategy for data exchange
    • From: noah_mendelsohn@u...
  • Re: Caution using XML Schema backward- or forward-compatibilityas a versioning strategy for data exchange
    • From: David Carver <d_a_carver@y...>