[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: Thu, 27 Dec 2007 18:38:54 +0000

David,

thanks for the links to your presentation and paper.

Insofar as the speed with which a standards body can/will respond to
change requests, as I'm sure you understand, they are sometimes in the
uneviable position of arbitrating between different members of the
community who, may be prepared to collaborate on standards efforts,
but are nonetheless are very often competitors. So politics is also a
factor. This is why I see extensibility as a strong requirement, that
is, to remove much of the tactics that could be employed when 2
trading partners want to progress an aspect of the standard which
others have no great interest in. Those efforts can feed back as
candidate changes to the standard that the commuity as a whole can
choose to adopt (or change) at a later date (early adopters accept
that possibility too).

Also, as I mentioned above, sometimes there is a need to carry
'private' data as part of a message exchange and the standard should
provide extensibility locations for this also (although this can in
some circumstances lead us into patterns such as 'must ignore' if the
message could be broadcast to others).

Fraser.

On 27/12/2007, David Carver <d_a_carver@y...> wrote:
> Fraser Goffin wrote:
> > Roger,
> >
> > I think in an earlier thread David Orchard contributed some comments.
> > I can't remember whether he included EXTENSIBILITY as a [special] type
> > of versioning. In particular the ideas around who 'owns' the
> > vocabulary and who can make changes. One of the things that I find
> > very difficult is where there is only central ownership and no ability
> > for distributed extensibility. Central ownership has very many plus
> > points, but at least one significant negative, namely, the speed of
> > change. In particualr information items that are [at least initially]
> > part of a private relationship between two (or more) trading partners,
> > but where the vast majority of the exchange is fulfilled by a
> > 'standard' schema. IMO extensibility (for the vocabulary user) is
> > essential and hels to reduce versioning 'churn' and more importantly
> > ensures that the core vocabulary does not constrain the business
> > operating model of those that want to use it.
> >
> That reason for extensibility is only necessary if the central authority
> can't or won't respond quicker.  Some of it has to do with the way
> vocabularies are designed and distributed to the members of those
> organizations.   I wrote about this back in December of 2006.
> Basically the central authority needs to adapt faster to their members
> chaning needs:
>
> Agile Schema Development.
> http://www.starstandard.org/index.php?n=STAR.XML2006
>
> We've been doing this for 3 years now, and it works extremely well.
>
> It definitely helps with backward and forward compatibility testing as
> well, at least from a structure stand point.
>
>

• References:
  • Caution using XML Schema backward- or forward-compatibility as a versioning strategy for data exchange
    • From: "Costello, Roger L." <costello@m...>
  • Re: Caution using XML Schema backward- or forward-compatibility as a versioning strategy for data exchange
    • From: "Stephen Green" <stephengreenubl@g...>
  • RE: Caution using XML Schema backward- or forward-compatibility as a versioning strategy for data exchange
    • From: "Michael Kay" <mike@s...>
  • RE: Caution using XML Schema backward- or forward-compatibility as a versioning strategy for data exchange
    • From: "Costello, Roger L." <costello@m...>
  • Re: Caution using XML Schema backward- or forward-compatibility as a versioning strategy for data exchange
    • From: "Fraser Goffin" <goffinf@g...>
  • Re: Caution using XML Schema backward- or forward-compatibilityas a versioning strategy for data exchange
    • From: David Carver <d_a_carver@y...>