OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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
>
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC