OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [security-services] Wondering what consitutes a "compatible" schemachange

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC