RE: Core 10 Draft document

[Chris McLaren <cmclaren@netegrity.com>]

One note, that might make the "kludge" a little easier to take, is that *we*
are not forcing people to use the xsi:type attribute--it's part of the
schema rules. That is, whenever you instantiate an element that has an
abstract type you HAVE to supply an xsi:type attribute substituting that
type with one that can be instantiated in order to have a valid document.

So we aren't adding the requirement that clients add this attribute as
additional overhead--it's already there as part of schema.

C.

> -----Original Message-----
> From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
> Sent: Tuesday, July 24, 2001 12:56 PM
> To: 'Chris McLaren'; Hallam-Baker, Phillip;
> 'Security-Services (E-mail)'
> Subject: RE: Core 10 Draft document
>
>
> 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
> >
> >
>
>
>