[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [security-services] Comments on core-21
I just realized something: Conditions does *not* have an abstract type. I thought we wanted to force people to write an extension schema so that their "mustUnderstand"-type semantics would be forced to be documented at least a little. But I may be behind the times. Can this question be added to the issue below? Thanks. Eve At 11:32 AM 12/11/01 -0500, Eve L. Maler wrote: >--------------------------------- ><AdviceElement>: >Section 2.3.3.1, line 284; and Section 2.3.3.2, line 369: > >The <Conditions> structure uses the <Condition> element as the only >obvious extension point, whereas the <Advice> structure not only has ><AdviceElement>, it also allows ##other namespaces without explicit >extension of the SAML schema. I just want to check that we have a >rationale for this -- with conditions, we want to force them to extend the >schema, right? And with advice, it's okay to use the SAML schema as is >because it won't change the native semantics? But then in the case of >advice, I'm not sure why we need <AdviceElement> at all, because they can >always extend <Advice> to require whatever they want, and either way you >still need an extension schema because <AdviceElement> has an abstract type. > >So I guess the net is, I suggest we get rid of <AdviceElement>, whose name >is awkward anyway. And we should probably explain the theory behind the >two different extension approaches in Section 5 (which I'm planning to do >anyway). -- 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