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: Using attributes


Some comments below.



> Phillip Hallam-Baker wrote:
> Since we are getting down to syntax, what use do we want to make of attributes? We have a number
> of options:
> 1) Encode everything in elements in the manner of SOAP

SOAP does not exclusively use elements. From where do you draw this 

> 2) Encode everything as an attribute if it has no internal structure.
> 3) Variations of both.
> If we are going for (3) then I would like to suggest that the following are attributes:
> Basic Information:
>     Version, AssertionID, IssueInstant, Issuer, RequestID
>     [NotBefore, NotOnOrAfter]

My basic rule of thumb (FWIW) is that if something *qualifies" something
else, treat it as an attribute on the element that it qualifies.
Of course, this rule doesn't hold true in all cases, but I have found it
a useful guideline. Thus, the list above seems reasonable to me.

> Permissions, instead of the permissions list structure I would like to have a sequence of
> attributes:
>     <Permissions Permit="Read" Permit="Write" Permit="Delete"
>         Permit="http://someextension.test/sss">

This is not valid XML since only one attribute with a given
name is permitted on any given element.

Typically, something that suggests a plural (Permissions in this instance)
would be best represented as a sequence of elements, possibly without the
use of attributes in this case:

Note also that in the example above, it would probably be best to
have a consistent typing of the content. An URI type would
seem to be in order here, given that you seem to imply in your example
that one can define one's own set of permissions by giving it a
name (A URI). Given that, it would seem that the following would
be in order:


which has a corresponding schema of something like the following:

        <xsd:element name="tns:Permissions" type="tns:Permissions.type"/>
        <xsd:simpleType name="Permission.type">
                <xsd:restriction base="xsd:uriReference"/>
        <xsd:complexType name="Permissions.type">
                        <xsd:element name="Permission" 

> The other issue I am trying to work on is which of the umpteen different ways of defining XML
> schemas to use. I not that Dave sometimes introduces abstract types, other times does not. This
> has implications for extensibility, quite what those implications are is not so clear to me.
> Phillip Hallam-Baker FBCS C.Eng.
> Principal Scientist
> VeriSign Inc.
> pbaker@verisign.com
> 781 245 6996 x227

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

Powered by eList eXpress LLC