[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC