[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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 > >
Phillip Hallam-Baker (E-mail).vcf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC