RE: [security-services] Wondering what consitutes a "compatible"schema change

[Scott Cantor <cantor.2@osu.edu>]

> 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).

Thanks, part of my intent in asking was to discover exactly where the definition came from. ;-)

I think terminology here can be tricky, because I would consider that to be more like forward compatibility than backward
compatibility, personally. The "new" format is *not* compatible with the old format, but the "old" format is subset-compatible with
the new format.

It seems to me that adding an optional ID attribute satisfies (a) and (c), except in the case I noted, in which somebody derived a
new type on their own and added that attribute.

That could be worked around of course by namespace-qualifying the one we add, but we haven't done much of that.

Anyway, consider me strongly in favor of adding an ID attribute to our signable elements *now*. If we can do this, much of the
language about dsig becomes much simpler to formulate and people will be much more inclined to do things consistently if they can
use xpointer and just stop.

IMHO, though we could eventually decide in 2.0 to make AssertionID et al. themselves ID type instead of string (which would not be a
compatible change), the advantage of that is outweighed by the pain of not having them asap.

-- Scott