RE: Core 10 Draft document

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

Ah, now I understand what the idea is. Essentially we either have to use
substitution groups or to use the xsi:type kludge. I don't much like the
attribute solution, but the substitution group route does not look to be
easily extensible.

	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: Monday, July 23, 2001 9:35 PM
> To: 'Hallam-Baker, Phillip'; 'Security-Services (E-mail)'
> Subject: RE: Core 10 Draft document
> 
> 
> > 	The errors fixed were to remove the definition of elements of
> > certain abstract types that are not intended for actual use
> > (Assertion,
> > Request, Response) and to create elements of the three
> > defined assertion
> > types.
> 
> My understanding of schema may be at fault here, but I had 
> done this on
> purpose. My understanding of type substitution (as opposed to element
> substitution) is that if you declare an element and assign it 
> a type that
> has been declared abstract, then what you are really saying 
> is "This element
> will have its type replaced at runtime with a concrete 
> descendant type".
> 
> The idea is that you have an element such as <Assertion>, for 
> example, that
> is of an abstract type (I.e. "AssertionType"). Since the type 
> of the element
> is abstract you can not instantiate it as such. However, you could
> instantiate it with a descendant type that is concrete.
> 
> So while you could not have an <Assertion> element, you could have an
> <Assertion xsi:type="saml:AuthenticationAssertionType"> element.
> 
> Doing the substitution this way allows you to declare 
> containers, such as
> the AssertionSpecifier for example, that will contain an of 
> the descendant
> types.
> 
> Unless my understanding is wrong, and it may well be, if you declare
> AssertionSpecifier as:
> 
> <element name="AssertionSpecifier" 
> type="saml:AssertionSpecifierType"/>
> <complexType name="AssertionSpecifierType">
> 	<choice>
> 		<element ref="saml:AssertionID" />
> 		<element ref="saml:Assertion"/>
> 	</choice>
> </complexType>>
> 
> then you can't put an <AttributeAssertion>, for example, into 
> it unless you
> create a substitution group with the <Assertion> element at 
> its head and
> assign <AttributeAssertion> to that group. Thus having global 
> elements for
> the descendants, without a substitution group, is useless 
> since you couldn't
> put them in anyway.
> 
> If I'm completely off here, please let me know, but based on 
> what I gathered
> in my quick readings of the schema rules, the way it was done 
> would work. Of
> coure the other scheme would also work with appropriate 
> substitution groups
> being defined, but results in the need for many more elements 
> at the global
> level. (The issue of which way to do this is discussed, by 
> the way, in the
> schema issues section of the Orchard-Mahler document).
> 
> > 3) Use of element/ref definitions
> > 	Still some work to be done here, when to use a ref and when to
> > define an element type?
> 
> Again, this was done very consciously, but may have been done 
> incorrectly if
> my understanding of the schema rules is wrong. Here I thought 
> the idea was
> that you created an element at the global level if you were 
> going to use it
> in more than one place, and then you used "ref" to refer to 
> that element
> wherever you wanted to use it. So, for example, the 
> <Evidence> element is
> declared globally and then used by reference in both the
> AuthorizationDecisionAssertionType, and in the AuthorizationQuery.
> 
> I made an effort to ensure this was set up to create global 
> elements only in
> the cases where the elements would be used more than once in 
> the definition
> of other types, or in cases where the element might need to 
> be reference by
> outside specifications.
> 
> Again, if my understanding is wrong, please let me know, as I 
> am by no means
> a schema expert. I'd be delighted to see the specific issues 
> you have with
> this.
> 
> 5) Descriptive text
> > 	Quite a few elements are lacking descriptive text, will
> > take this
> > from wherever it can be found for the core11 draft.
> 
> Which ones in particular are you lacking text for? I thought 
> they were all
> addressed to some degree or other in the discussion papers.
> 
> 
> C.
> --
> Chris McLaren, Principal Engineer
> B2B Research Group  Netegrity, Inc.
> cmclaren@netegrity.com   chris.mclaren@ieee.org
> 
>

Phillip Hallam-Baker (E-mail).vcf