Re: [xml-dev] Caution using XML Schema backward- or forward-compatibilit

[David Carver <d_a_carver@yahoo.com>]

Michael Kay wrote:
>> 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.
>   
Not necessarily, the number of people to get something approved doesn't 
have to affect the group as whole. Notice of proposed changes are 
broadcast to all members that are intersted in that particular 
specification and proposed change is sent to all members. A call is held 
to review the proposed change, those that are interested or have issues 
with the change, can participate on the call, and changes are adopted 
accordingly. Modifications are done to the schemas, produced in nightly 
or biweekly milestone releases for review. Issues that come up are 
addressed as they are received.

Those that are interested in the changes, needn't participate. It puts 
the emphasis back on the members that are interested in a particular 
standard to participate instead of waiting. They have plenty of time to 
voice concerns.


> 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.
>   
In our situation, we don't produce a Schema that is to be extended. 
These are master schemas that cover the overall requirements. If a 
member wants to customize or narrow the scope of the schema they can do 
so themselves, with the caveate that whatever narrowing they do still 
validates against the Master schema.

The point of the paper is to show that the development does not have to 
take years to get something into the hands of the members that are using 
it. Businesses can't wait years for their requirements to make it into 
the official standard. We still only do an official public publication 
once a year. But members can get access to Milestone snapshots every two 
weeks through out the year, nightly builds if necessary, and all 
requirements are validated using Unit Tests to make sure no requirements 
were accidently deleted or changed.

Again, we are taking the approach of developing the master schemas, 
which if necessary can be profiled down by members as not everybody 
needs everything in the schema. However the closer you are to the 
master, the less interoperability problems (i.e. unexpected data, etc) 
will occur in our experience.

I agree that there is an element of politics that can occur, and again, 
it depends on how the standard organization addresses those issues. If 
the process isn't iterative in development of the standard, then those 
typical issues will have a greater impact from our experience. Since 
going this route, all of our members are happier as their own 
development is slowed, and they are bring their requirements back to us 
sooner so that they can be included. Essentially helping to eliminate 
the need for the customized extensions that Fraser mentioned.

It does take a fundamental change and the standard organization needs to 
be will to adopt to that change in order for it to work.

I'd recommend looking at the Standards to see how they are structured, 
we don't have One master schema that is used for every business process, 
but do build on top of several libraries of components and fields, to 
construct the messages being sent.