RE: Issues to be closed at the Sept 4 Concall

[It looks like I'm re-subscribed properly.  Ahhhh. :-]

At 01:53 PM 8/30/01 -0400, Hal Lockhart wrote:
>Eve wrote:
> > I'd like us to reconsider the following issue:
> >
> > DS-4-05: SingleSchema
> >    I may have missed any discussion of the rationale for
> > having one vs. two
> > schemas.  Understanding that assertions can be used entirely
> > without the
> > request/response layer in some scenarios, I'm willing to
> > believe that two
> > is the right answer, but I'd like us to document our
> > rationale because
> > there are costs to having two namespace names, defining things like
> > majorVersion and minorVersion twice, etc.
>
>First, that is the rationale, so perhaps we just need to say so somewhere.
>I'm not sure where because we decided that the spec would not say "why" and
>it clearly is not a security consideration.
>
>Second, I'm confused about your concerns. You do understand that the
>protocol schema imports the assertion schema? I thought we were making
>practially everything Global, so the definition would only appear in the
>assertion schema and be referenced in the protocol schema.

Well, yes, but...  Here are some consequences of having two separate 
schemas identified with two separate namespaces:

- We need to qualify (e.g., prefix) elements in two different ways.
   For example, here is how an instance of a response might look:

   <saml-p:Response
     xmlns:saml-p="http://www.oasis-open.org/committees/security/docs/
     draft-sstc-schema-protocol-15.xsd" ...>

     <saml-a:Assertion
       xmlns:saml-a="http://www.oasis-open.org/committees/security/docs/
       draft-sstc-schema-assertion-15.xsd" ...>

     <!-- assertion innards -->

     </saml-a:Assertion>

   </saml-p:Response>

   I've used two different prefixes here.  I could have used the same
   prefix (as long as I wasn't putting both xmlns: attributes on the
   same element), or I could have used defaulting so that no prefixes
   appear at all, but it may be confusing to users that there have to
   be two namespaces declared unless we explain it.

- Any attributes that appear on several elements need to be either
   declared in both schemas (what's done currently for Version and
   presumably what's done in the not-yet-published core-16 for majorVersion
   and minorVersion), or defined as global attributes (strongly
   UNrecommended in this case), or defined as an attribute group in
   the inner schema and then referenced from the outer schema, or
   possibly defined in some extremely high-level complex type that's
   an ancestor to the types for Request, Response, and Assertion.  I would
   prefer one of the latter two options so that we don't duplicate code.

Here are the consequences of using a single schema that combines both:

- The schema structure doesn't inherently indicate that we intend for
   certain "inner" elements (namely Assertion and its ilk) to be usable
   as top-level elements.  This doesn't prevent use of any element as a
   top-level element, but it could look a little confusing.

- Scoped key constructs might get broken.  E.g., if we were using XML
   Schema's unique key facility to ensure that some "ID" attribute were
   unique across all the Assertion elements in a Response, the XPath
   used to describe the scope would mention the Response element.  Any
   use of Assertions outside the use of Response wouldn't get checked
   by schema validators for uniqueness of their keys.  We don't use
   keys right now so that's not a concern, but it might be in the future.

>If documenting the rationale is all that is needed, I would still like to
>close the issue. Can some editor commit to putting it in their document?

Based on the above analysis, I do feel comfortable having two schemas 
instead of one.  If anyone DISAGREES with this, then DS-4-05 should 
probably stay open, but everyone AGREES (e.g., by not replying to this 
message :-), then we could safely close it.

The editorial request for the actual SAML core-nn draft would be to 
correct/clarify any examples that use a single saml: prefix or presume a 
single namespace, because this could be misleading.

We do seem to need a non-normative place to hold rationales, for schema 
design if for nothing else.  Would a separate document on this be 
useful?  (E.g., it could include the information from the thread on naming, 
as well as the other rationales we discussed this week.)  I'm willing to 
put one together, but wouldn't be able to make any progress on it for a 
couple of weeks.

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