OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Core-19 schema comments

At 07:33 AM 10/3/01 -0700, Hallam-Baker, Phillip wrote:
> > - 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

(Were you going to say more?)  Yeah, I struggled with which one to 
recommend, and I could see using an attribute group too.  To date we 
haven't used model groups or attribute groups, so I *suppose* that would be 
a reason for avoiding them, but if we really have no need for a 
root-element semantic, then a group is fine.

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

Actually, I just checked, and there's already a built-in called 
positiveInteger.  So you could use that directly.

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

So is your preferred naming scheme SingleAssertion etc.?  That seems 
okay.  I'm still noodling on a slightly different way to cut things here; 
don't know if I'll be able to come up with anything better...

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

How would it do that?  I must be missing something obvious.

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

Yeah, this would be fairly substantial.  But we normally favor element 
content over attributes, so it seems odd to put "content" in an attribute.

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

Oops, yeah, you're right.

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