[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [security-services] Wondering what consitutes a "compatible"schema change
My intent, anyway, was to ensure that old instances can validate against the new schema (syntax), and that application behavior with respect to old instances doesn't change (semantics). I think this amounts to your (a) and (c). Eve Scott Cantor wrote: > I was just wondering what the precise definition was for deciding whether a change to the schema for 1.1 is "compatible" or not. In > particular, is the basis: > > a) whether an old instance validates against the changed schema? > > b) whether a new instance would validate against the older schema? > > c) whether an implementation using the older schema would need to change if it began validating according to the new schema but > applying assumptions and rules based on the old one? > > To bring up a high priority example, can we add an optional ID attribute to Assertion, Request, and Response to fix the signing > issues? Does the fact that such an instance would fail to validate against the original 1.0 schema matter, given that the new schema > could be placed into the older implementation and pretty much nothing would break? > > OTOH, if one derived a type from the old schema type and added such an attribute with the same name, it would break that > implementation, so I'm guessing the answer is no, but I'm just trying to clarify it. > > -- Scott > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > -- Eve Maler +1 781 442 3190 Sun Microsystems cell +1 781 354 9441 Web Technologies and Standards eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC