> It's still highly unlikely for there to be symbol space ambiguity given
> this setup, but still... I'd rather go for a goal of "as few options as
> possible, ideally one" (this was one of the original XML design
> principles), and pick one or the other. Since substituted elements have
> to be of compatible types with the head of the substitution group, and
> assuming this causes no problems with implementers, I'd go with types
> instead of elements all around as soon as practicable (and get rid of
> <RespondWith> :-).
I certainly agree that using types is sufficient, but could you clarify this ambiguity? How can somebody redefine what type
samlp:AttributeQuery is bound to?
All I see is two ways of accomplishing the same thing, but I don't quite see where there's a potential for ambiguity.
The reason I proposed text that introduced this problem is that the actual errata brought up was that the text *presumed* use of
xsi:type, but I guess that can be fixed by still requiring the type of the derived element to be used.
-- Scott
-- Scott
