Comments on the use of Substitution groups,and Phil's proposal to decouple the assertion header from the statements.

[Chris McLaren <chris.mclaren@ieee.org>]

First, on Phil's proposal: I think it's a good idea for all the reasons we
have discussed. For example having the <Assertion> element contain the
statements allows us to easily do things like "grab all assertions". The
additional degree of freedom of extending from statements, or from assertion
itself is also helpful.

The second issue is that of how we will specify in schema the various
statement types. As I understand it we have three options:

1) Use type substitution. All things will be of the form <Statement
xsi:type="AuthenticationStatementType>

2) Use subsitution groups. Statements will look like
<AuthenticationStatement>. (This contains the implicit notion that we will
block the ability of extension schemas to add to the subsitution groups--per
our discussion at the F2F.)

3) Explicit definition of the type of the assertion as a choice between a
pre-defined list of types. My understanding from Eve is that this is
functionally equivalent to the use of substitution groups with blocking. I'm
not going to discuss this as a separate option, but rather assume that it's
another way (and perhaps a better one) to arrive at the same result as 2.



Now after the F2F we are leaning towards the use of substitution groups with
blocking. My understanding is that this gets us the following benefits:

1) The actual documents are easier to read. Clearly
<AuthenticationStatement> is more easily understood by people who aren't
schema-heads than <Statement xsi:type="AuthenticationStatementType">.

2) We get better "ancestor" processing for cases where an extension is not
understood by the processor. That is, if I get an <AuthenticationStatement
xsi:type="McLarenSpecialAuthenticationType"> I can still deal with it as an
AuthenticationStatement even if I don't know what a
"McLarenSpecialAuthenticationType" is. In the type substitution case if what
I got was a <Statement xsi:type="McLarenSpecialAuthenticationType">, still
assuming I don't know what the definition of
"McLarenSpecialAuthenticationType" is, then I could only deal with it as an
instance of "StatementType" and not as an instance of
"AuthenticationStatementType".




It seems to me that those two arguments are enough to swing the decision in
favour of this solution, and that seemed to be the general feeling of the
TC.

However, I do feel the need to point out a couple of things about this
solution, just to make sure everyone understands the potential downsides of
this solution:

1) It is much harder to work with "Statements" at the top level of
abstraction. For example if you wanted to write some code to get the
"statement" inside an <Assertion>--something everyone will have to do, and
frequently--you would have to look for an instance of the <Statement>
element, or an instance of the <AuthenticationStatement> element, or an
instance of the <AttributeStatement>, or an instance of the
<AuthorizationDecisionStatement>. In other words, every time you want to
work with the general class of statements you have to handle the fact that
there are N (where N=4 in this case) different things you have to look for.

If, in the future you can have multiple statements in an <Assertion>, or
multiple <Assertion>s in some package, this problem continues and gets worse
by another order of magnitude.

Under the type substitution paradigm, on the other hand, you only look for a
<Statement> element. It is easier to work at the abstract level.

2) The addition of a new Statement type by the TC (as opposed to the
addition of a new type by other parties via extension) results in an
increase to the value of N, which essentially would break all existing code.
For example, assuming we add a "SessionStatement", and this is made
substitutable, then every place where we perform an operation on a statement
needs to be re-written to understand that a <SessionStatement> is also a
statement. Back to the example of getting a statement out of an <Assertion>,
the code to get the statement now requires a re-write to also check for the
<SessionStatement>.

Under the type substitution paradigm these changes by us to our schema don't
break processors that operate at the general level of statements. Only the
new code to handle the new type is necessary, not any changes to the
processors at the more abstract levels.



I don't know if these flaws with the processing at the abstract level of
statements are enough to swing the decision back, but I do feel that we need
to point them out. If I am wrong about these problems, I'd love to
understand why.

If we can address these problems inside the framework of the subsitution
group solution (or Eve's type choice variant), that would clearly be the
ideal solution.

C.