Re: Substitution Groups Reconsidered

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

At 11:43 AM 9/17/01 -0400, Hal Lockhart wrote:
>We are having trouble finding a Java data binding framework, either open
>source or commercial which supports substitution groups. Castor seems to be
>a leader in this area and it currently does not support them. Does anyone
>have any suggestions? Is this reason to reconsider substitution groups in
>SAML 1.0? We have seen some commentaries suggesting that substitution groups
>are an XML schema feature to be avoided. See for example:
>
>http://www.geocities.com/kohsukekawaguchi/XMLSchemaDOsAndDONTs.html

Kohsuke is a (very well respected) colleague of mine.  His article is quite 
provocative, given that many users of XML Schema precisely want the complex 
type functionality; in our case, it's one of our main motivations in our 
schema design.  However, I partly agree with his prescription.  Let me explain.

His rationales are:

1. To do substitution groups, you need to do properly named complex types,
    which he advocates against.

2. You can simulate substitution groups with <choice> groups more simply.

We need to do complex types anyway, so rationale #1 doesn't apply.

We agreed not to make substitution groups available to extension schemas on 
the principle of greatest partial understanding (e.g., if you don't have 
the extension type around, you're hosed when you see 
<MyAttributeAssertion>), so we're sort of agreeing with him when it comes 
to extensions of SAML.

Regarding substitution groups in our own schema, my final conversations 
with Chris McLaren at F2F #4 (which I hastily reported out loud at some 
point, I think) were that, now that we're disallowing substitution groups 
in extensions, there's no particular benefit to using them in our own 
schema; <choice> groups will work just as well.  In other words, with other 
considerations out of the way, I agree with Kohsuke's rationale #2 as 
well.  I was planning to make a bunch of comments on this and other schema 
matters to Phil this week...

On the matter of data binding: You're no doubt right that there's little 
support for the substitution group type hierarchy in data binding 
software.  I don't think anyone really expects them to be used this way at 
this point; their interesting power is supposed to be in validation, and 
<choice> groups provide the identical validation power, though in a more 
autocratic fashion.

The paragraph people can skip if they really don't care what I mean by 
"autocratic" :-): If you use <choice> groups, the power of saying which 
elements get to be the choices resides in the declaration of the 
*containing* element's declaration.  If you use substitution groups, the 
power resides in the declaration of any element that wishes to substitute 
itself.  Since we own and maintain the whole SAML schema ourselves, and 
since we will turn off the ability of extension schemas to have this type 
of control (with the "block" attribute), we get to say what's substitutable 
anyway -- so we might as well use the top-down method.  It also makes it 
easier to read the schema, since all the choices are listed together.

More examples or explanation on request, but I think Hal's basically right, 
though for different reasons.  I do think we made the right decision in 
removing the need to use xsi:type when only the native SAML schema is in force.

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