RE: Use of Substitution groups?

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

On the timing, I am currently editing the core doc on the basis of the
consensus schema with some reordering of elements but without substitution
groups.

I will probably punt on the description of certain linkages within the
schema for now since one of the reasons I would like to make the change is
to make some things easier to explain.

There are a couple of other changes that would make the explanation somewhat
easier, for example declaring all elements that are of a saml specific type
as toplevel elements would allow the prose to refer only to elements rather
than having to switch back and forth between elements and types.

I don't think we should come to a decision on this topic before I release
the 11 draft, and even if we did reach a decision I won't get arround to
editing it until the next revision cycle. However I don't think we need to
avoid discussion. Parallel processing is a good thing.

		Phill


Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Chris McLaren [mailto:cmclaren@netegrity.com]
> Sent: Tuesday, July 24, 2001 4:12 PM
> To: 'Hallam-Baker, Phillip'; 'Security-Services (E-mail) (E-mail)'
> Subject: RE: Use of Substitution groups?
> 
> 
> I hope your intention is to open this as an issue for 
> discussion _after_ the
> consensus schema is accepted by the TC. I agree that it needs to be
> discussed (this is the reason it is called out as an issue in 
> the discussion
> doc), but I think we can leave it until after the committee 
> accepts the
> consensus doc.
> 
> Assuming that is the case, a few other notes for everyone to 
> consider on
> this issue, in preparation for that discussion:
> 
> 1) Note that either solution provides the same features, it's only a
> question of howl the SAML document looks.
> 
> 2) The "W3C XML Schema Design principles" section of the 
> Orchard-Mahler
> proposal is really required reading for this discussion. Also 
> it links to
> many interesting readings on the topic.
> 
> 3) The decision of how to do inheritance affects more than just the
> assertion types. In the proposed schema we have type substitution
> inheritance taking place in the <Assertion> element, in the 
> <Condition>
> element, and in the <SAMLQuery> element. As Phil notes, the 
> <Condition>
> element would need to be promoted in order to become the head of a
> substitution group. I would assert that it makes sense to use the same
> 
> In general, I can see arguments for both sides, and I would 
> like to see a
> broader discussion within the TC on this point--ideally with 
> some commentary
> from people who have worked with both substitution groups and type
> substitution in the past on other XML languages.
> 
> C.
> 
> > -----Original Message-----
> > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
> > Sent: Tuesday, July 24, 2001 4:21 PM
> > To: Security-Services (E-mail) (E-mail)
> > Subject: Use of Substitution groups?
> >
> >
> >
> > All,
> >
> > 	Starting from the core-schema-assertion-10.xsd
> > proposal, I suggest
> > that we use substitution groups in place of the current mechanism.
> >
> > [Incidentaly we have traced the cause of the previous
> > problem, I was working
> > from the documents sent to me by Prateek which had
> > <AttributeAssertion>
> > elements in the examples, it turned out that I had been sent
> > an earlier
> > version of the document than the one that went to the list
> > and had assumed
> > that the two were the same except for the Visio documents.]
> >
> >
> > The practical imporance of this is what the toplevel elements
> > look like,
> > whether it should be
> >
> > <Assertion xsi:type="AttributeAssertionType">
> >     ...
> >
> > or
> >
> > <AttributeAssertion>
> >     ...
> >
> >
> > In order to make this change we would have to add in the
> > following element
> > definitions:
> >
> > <element name="AuthenticationAssertion"
> > 	type="saml:AuthenticationAssertionType"
> > 	substitutionGroup="saml:Assertion"/>
> > <element name="AuthorizationDecisionAssertion"
> > 	type="saml:AuthorizationDecisionAssertionType"
> > 	substitutionGroup="saml:Assertion"/>
> > <element name="AttributeAssertion"
> > 	type="saml:AttributeAssertionType"
> > 	substitutionGroup="saml:Assertion"/>
> >
> > [The condition type would also need modification to match, 
> this would
> > involve promoting condition to a toplevel element first since
> > substitution
> > groups have to be top level elements]
> >
> > The one complication to extension is that the extension
> > schema would have to
> > remember to include to include the line adding the element to the
> > substitution group.
> >
> > On the plus side this would simplify DOM type programming
> > since one can pull
> > out assertions of a particular type with a single selector 
> rather than
> > having to first select on the element name and then filter on
> > xsi:type.
> >
> >
> > 		Phill
> >
> >
> >
> > Phillip Hallam-Baker FBCS C.Eng.
> > Principal Scientist
> > VeriSign Inc.
> > pbaker@verisign.com
> > 781 245 6996 x227
> >
> >
> >
>

Phillip Hallam-Baker (E-mail).vcf