Core-19 schema comments

["Eve L. Maler" <eve.maler@sun.com>]

Here are comments on the core-19 schemas, purely from a "schema
perspective" (i.e., not particularly concerned with the semantics
that these constructs are supposed to represent).  I have included
line numbers for reference.

BTW, I apologize if some of these items have been discussed
before. I've been doing my best to keep up, but I suspect my best
hasn't been good enough...  If I suggest something below that's
explained in the spec or has been hashed over to death on the
list, please be kind to me and tell me so. :-)

*Comments that affect both schemas:

- We need to consider what the right XML namespace names will
   eventually be for these two schemas.  I'm not fond of actual
   file names here, though I recognize that tools may be happiest
   with this (not exactly conforming) solution.

- In protocol-19 lines 25-26 and 93-94, and in assertion-19 lines
   25-26, the MajorVersion and MinorVersion attributes are defined
   over and over again.  There are two possible solutions to this
   redundancy.  1. Define an "ur-type" (called, say, RootElement)
   that defines the attributes that must appear on SAML elements
   that are allowed to be "roots" as far as SAML is concerned and
   then have RequestAbstractType, ResponseType, and
   AssertionAbstractType inherit from it.  2. Define an attribute
   group in assertion-19 that can be referenced in all three
   places. I think #1 is the better solution, if we can agree on
   the semantics of RootElement.

- Again regarding MajorVersion and MinorVersion, I thought we were
   going to use facets to ensure that the integer is positive.  We
   would want to make a VersionNumberType simple type for this.

*draft-sstc-schema-assertion-19.xsd:

- Lines 12-18 (the definition of DecisionType) would be more
   consistent with the style used in protocol-19 if it were moved
   before the first element declaration.

- The AssertionID element (defined on line 8) has a confusing
   name, given that there is an AssertionID attribute that
   *assigns* IDs, and given that the purpose of this element is to
   *reference* assertions that have such assignments.
   AssertionReference would be a better name.

- AssertionType (defined on lines 32-44) wants to use <choice>
   rather than <sequence>, I think.  Also, this design doesn't seem
   to match up to the core spec (single/multiple vs.
   AssertionSimple and AssertionList).

- SubjectType (defined on lines 81-87) provides minOccurs and
   maxOccurs for the individual elements in the <choice> group, as
   well as making the <choice> group be repeatable.  The inner
   occurrence indicators are superfluous.

- SubjectConfirmationData (defined as a local element on line 92)
   should be made into a global element.

- NameIdentifier and its type (defined on lines 97-101) add up to
   an empty element.  I would have thought that NameIdentifier
   should have content, say, what's currently in its Name
   attribute.

- I'm not sure that we really need the AssertionSpecifier element
   (defined on line 59).  Since its contents consist of a single
   choice among AssertionID, Assertion, AssertionSimple, and
   AssertionList, and since SubjectType and AdviceType reference
   this element in the context of an unbounded (repeatable)
   <choice> group, the parent element seems to serve no particular
   function. I can sort of see the use of the AssertionSpecifier
   type (defined on lines 60-67), which is used in the definition
   of Evidence, but even there it might be just as easy to name the
   desired elements one by one.  (The protocol-19 schema, in its
   definition of ResponseType on lines 97-108, references a set of
   elements that is almost but not quite the whole list of
   AssertionSpecifier elements.  So the reuse possibilities of this
   element/type aren't even very great.

- In the ConditionsType definition on line 175, the <choice> group
   has a minOccurs of 0, but since the entire Conditions element is
   optional, I think the minOccurs should be 1.

As I review the spec, I will probably note additional "semantics"-
related comments that might affect the schema.

Thanks,

	Eve
--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com