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
