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] Caution using XML Schema backward- or forward-compatibility as a versioning strategy for data exchange

> That reason for extensibility is only necessary if the 
> central authority can't or won't respond quicker. ...
> organizations.   I wrote about this back in December of 2006.   
> Basically the central authority needs to adapt faster to 
> their members chaning needs:

All true. But the reason it tends to react slowly is that changes can have a
wide-ranging impact, and therefore lots of people need to be consulted and
lots of existing systems regression-tested. I don't see anything in your
paper that addresses the problem that the larger the number of stakeholders,
the longer it takes to get anything approved.

I also don't see anything in your paper about specializing a schema. Typical
scenario: application A1 receives a message of type M1 and requires that
message to conform to constraints C1. A new application A2 then comes along
that requires a message of type M2, which has a high similarity to M1. What
do you do? Perhaps you define a new schema, M0, and then define M1 and M2 as
subtypes of M0. But in my experience, the tools for achieving that, and for
managing the resulting collections of definitions, don't yet exist. Perhaps
you take the easy route, and use M0 for everything. But then application A1
risks receiving data that doesn't satisfy the constraints in C1, that is,
data that A1 considers invalid.

Michael Kay

[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