[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC