RE: Core-19 schema comments

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

> *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.

The idea is not to use the final namespace until we have a schema
that is more or less complete.

> - 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.

I would prefer an attribute group (i think). The use of inheritance 

> - 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.

Sure, what does the schema look like?

> *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.

Fixed, see below

> - 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.

OK the element becomes AssertionIDReference and is defined along with 
AssertionSpecifier.

> - 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).

Agh! I had made the change... Simple and list did not seem quite 
the right names. Also the order of the words was the wrong way
since we are using the parent type as a sufix not a prefix in the
rest of the schema.

> - 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.

Done

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

Done (although the outcome of the attributes discussion might change this).

> - 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.

Hmm, Could do that... I'll not change the schema just yet.

> - 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.

It seemed like a good idea at the time. Does anyone want to defend it?

> - 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.

No, the conditions element may be used without conditions to specify the
notbefore/notonorafter validity interval.


	Phill

Phillip Hallam-Baker (E-mail).vcf