RE: Substitution Groups Reconsidered

["Eve L. Maler" <eve.maler@sun.com>]

At 11:00 AM 9/17/01 -0700, Hallam-Baker, Phillip wrote:
>The article appears to me to be saying 'here's why not to bother learning
>about these things, you can get along without them'.
>
>However the choice mechanism does not permit the declaration of new
>assertion types as first class extensions of SAML and is thus unacceptable.

Neither do substitution groups.  They just allow the declaration of new 
*elements* as optional choices instead of the head element.

>Since we have gone over this at length at the F2F it is disappointing that
>the matter is being re-opened. Other groups who want to build on top of SAML
>(XACML) are already working on the assumption that SAML will permit
>extension to meet their needs. The idea that SAML should be arbirarily
>restricted to a particular problem domain, both in version 1 and in all
>future versions is not supported by any use case or requirement and indeed
>is directly against the original principles the group agreed upon.

What I said about "block" has nothing to do with other people who are using 
SAML and extending it for their own purposes.  They can, at any time, 
"substitute" a type of their own for an ancestor SAML type, using 
xsi:type.  (I haven't looked closely at your experimental extension 
schemas, but I bet they use xsi:type for their extensions and thus wouldn't 
be bothered at all by what I'm suggesting.)

What I thought we agreed to was that extension schemas wouldn't be allowed 
to substitute an *element* of their own; they would be forced to use 
xsi:type instead, which would connect every extension semantic back to a 
native SAML element semantic, like this:

   <MyAttributeAssertion xsi:type="saml:AttributeAssertionType">...</>

Currently, and in every previous version, both have been implicitly allowed 
(though we never talked about the second case):

   <MyAttributeAssertion xsi:type="saml:AttributeAssertionType">...</>
   <MyAttributeAssertion>

The question we're discussing is whether to disallow substitution groups in 
extension schemas with "block" -- NOT whether to disallow extension of 
types with "final" -- so that we force all extended forms of SAML to use 
our native elements on the principle of greater partial understanding.

Obviously there is still considerable confusion over these methods, despite 
the lengthy discussion we had in Waltham.  If we discover that our F2F #4 
agreements don't mean what we thought they meant, it seems to me that 
(unfortunately) we have no choice but to go through the logic again.

         Eve
--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com