RE: Core 10 Draft document

[Chris McLaren <cmclaren@netegrity.com>]

> 	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