2 Issues: Assertion Types, Self-describing assertions

["Orchard, David" <dorchard@jamcracker.com>]

There are 2 issues that have arisen in our discussions about assertions.  I
have separated them out.  I draw a distinction between strong typing, which
is whether there is are many types that can determine the validity of
instances, and self-describing types, which is where the type information is
with the instance at the message level (as opposed to post-parse or
validation level).  

Assertion types: What should the type hierarchy of assertions be?  The
options are:
1) Abstract assertion type with concrete sub-types (strongly typed)
2) No abstract assertion and concrete types (strongly typed)
3) Single assertion type with optional content (weakly typed)

A sample way #1 would look in schema:
<xsd:complexType name="AssertionType"></complexType>
<complexType name="NameAssertionType">
<extension base="saml:AssertionType">
</complexType>
<complexType name="AuthenticationAssertionType">
<extension base="saml:AssertionType">
</complexType>

My preference is for option #1.  The advantage is that a collection of
Assertions can be passed around, and when new sub-types are added the
receivers don't break at the schema validation step.  Additionally, the
recipient can validate the types against the ones they understand, such as
NameAssertion or Authentication Assertion or Session Assertion.  For
example, a reciepient receives a Name and Authentication Assertion.  It
validates the types that it has.  Now perhaps a newer Name assertion was
also received.  The recipient could easily respond with "I understand the
first Name and Authn Assertions, but not the second Name Assertion".  Now
SOAP gives us a "MustUnderstand" field, which seems ideal for the sender to
say which fields the recipient must understand - say the first Name and
Authn Assertion.

On to the collection type... A Collection of Assertions type with a Size
field would look like:
<complexType name="AssertionListType">
	<sequence>
	<element ref="Size"/>
		<choice>
			<element name="Assertion" type="saml:AssertionType"
maxOccurs="unbounded"/>
		</choice>
	</sequence>
</complexType>

I believe we are not only going to have to define the assertion type(s) but
also the collections of same.  

Issue[ Self-describing types]: Should assertions contain their type
information?  XML schema allows an element to refer directly to it's type,
using the xsi:type attribute.  For example, <NameAssertion
xsi:type="saml:NameAssertion"/>.  The options are:
1) Include types with instances
2) Do not include types with instances.

I believe we should do option #2.  It is clear to me that many schema
parsers will automatically "stitch" the type information with the instance
information and make it queryable, so we don't need to make our spec more
complicated by having another requirement.  Let's keep our spec simple.
(Dark Night of the Type system?)

FYAI (For Y'All Information) There's a really cool thing that's being worked
on, called the Post Schema Validition Infoset (PSVI).  The proposal on the
Schema for PSVI is at http://www.cogsci.ed.ac.uk/~richard/infoset/notes.html
.  After schema validation, you'll be able to query an element for it's type
information, kind of like Java introspection.  To show how this is an
interesting emerging talk, From Martin Gudgin's talk at nyc,  "The XML
Schema language provides type information about XML documents to
applications. This type information is made available through
Post-Schema-Validation Infoset contributions. This session looks at several
API approaches to accessing this information including DOM extensions and
event based mechanisms. "  

I'm also pretty sure that eventualy XQuery will do something with this as
well, so you can do queries based upon type information.  But that's an even
later eta FYAI. 

Dave Orchard
XML Architect
Jamcracker Inc.,    19000 Homestead Dr., Cupertino, CA 95014
p: 408.864.5118     m: 604.908.8425    f: 408.725.4310

www.jamcracker.com - Sounds like a job for Jamcracker.