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] Two issues on Advice


The abstract type allows an element to be declared that can ONLY be used as
advice.

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@sun.com]
> Sent: Wednesday, February 13, 2002 8:28 PM
> To: security-services@lists.oasis-open.org
> Subject: [security-services] Two issues on Advice
> 
> 
> An engineer here just asked two questions which caused me to 
> notice the 
> following issues.  I don't expect them to get into core-27, 
> but for the record:
> 
> - Minor: The Advice element schema (line 590 in core-26) has 
> a sequence
>    surrounding an unbounded choice.  I think the sequence 
> element can be
>    removed, as it has no impact.
> 
> - Major: Why do we go to the trouble of having an <AdviceElement> with
>    an abstract type (so you have to use xsi:type) when we also allow
>    ##any?  There is no incentive to derive a type from 
> AdviceAbstractType
>    when you can just supply whatever elements you want.  I 
> think we could
>    safely remove AdviceAbstractType and AdviceElement altogether.
> 
> 	Eve
> --
> Eve Maler                                    +1 781 442 3190
> Sun Microsystems XML Technology Center   eve.maler @ sun.com
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 

Phillip Hallam-Baker (E-mail).vcf



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


Powered by eList eXpress LLC