[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: FW: Comments on the use of Substitution groups,and Phil's proposal to decouple the assertion header from the statements.
Hi Chris,
[Can you please forward this to the list? My posts are
bouncing right
now. Thanks!]
At 06:00 PM 8/29/01 -0300, Chris McLaren wrote:
>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.
I agree that allowing the "factoring out" of metadata from one
(or,
particularly, multiple!) assertions can make sense,
and since Phill has
particular extension scenarios in
mind that make use of multiple assertions
grouped
together, we've perhaps got a concrete reason to want to do this.
The two-level terminology is something that we've struggled with
for
months. I have to say that "Assertion"
(high-level metadata wrapper) vs.
"Statement" (low-level
thing that actually contains the substance of the
assertion) really doesn't help things, and is similar to the old
"Assertion" vs. "Claim" language that caused so much
confusion.
This week, Phill used something like "assertion package" to
describe the
higher-level wrapper, which is pretty
similar to some of the names Dave and
I were batting
around in our draft. In accordance with the SSTC domain
model and all the discussions we've had to date, I think the lower-level
construct has to be (or end in) "Assertion". For
the higher-level
construct, I would find the following
terms workable:
AssertionPackage (preferred because it doesn't discriminate
against
single-assertion innards)
AssertionSet
AssertionList
AssertionGroup
>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.
It's actually a choice among elements, not types. I'll
expound on this to
the whole list only if some others
clamor for it. :-)
>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">.
A small benefit, but teachability is one sign of a good standard.
>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".
Correct.
>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.
Well, yes, but if you have access to types, you should
theoretically be
able to key off of "all elements whose
type is Assertion or a descendant of
Assertion".
Also, I would think that the most interesting processing of
the various assertions is the stuff that's *different* between
them. If we
factor out the metadata into a
package-level element, then that processing
can happen
on occurrence of that element. The remaining commonalities are
things like the Subject element, which I would guess is
probably going to
be processed differently depending on
whether it's in (e.g.) an AuthN
assertion or an Attrib
assertion.
>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.
I've worked with DTDs that have many dozens of choice options in
some
contexts. This is child's play. :-)
Seriously, as long as these elements
have a common
ancestor type, I don't see the worry.
>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.
It doesn't break them "syntactically", but semantically they
still won't
have a clue (unless, again, they have access
to the common ancestor type of
interest). I see
what you're driving at, but it seems like an impossible
goal to build perfect silent upgradeability into any XML language, and
adding new assertion support in one's and two's seems
reasonable.
FWIW, I'm not sure this would help, but maybe we should consider
publishing
new revisions in two forms: A real update to
our SAML schemas, plus a
"temporary extension" schema
that mimics the changes but uses the xsi:type
paradigm.
>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.
Eve
--
Eve
Maler
+1 781 442 3190
Sun Microsystems XML Technology
Center eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC