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


At 11:32 AM 12/11/01 -0500, Eve L. Maler wrote:
>Section, line 284; and Section, 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 

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