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


After discussing this with Eve, I better understand
your comment regarding enumeration values being
extended.

Another approach would be to treat the permissions
as elements, namespace qualified, of course. That would
allow for extension and at the same time provide for
schema validation.

e.g.

<s:Permissions xmlns:s="http://saml.org/">
	<s:Read/>
	<s:Write/>
	<x:sss xmlns:x="http://someextension.test"/>
</s:Permissions>

The schema would look something like the following:

	<xsd:element name="Permissions" type="tns:Permissions.type"/>
        <xsd:simpleType name="Permission.type">
		<xsd:restriction base="xsd:string">
			<xsd:maxLength value="0"/>
		</xsd:restriction>
        </xsd:simpleType>
        <xsd:complexType name="Permissions.type">
                <xsd:choice maxOccurs="unbounded">
                        <xsd:element name="Read" 
                                type="tns:Permission.type"/>
                        <xsd:element name="Write" 
                                type="tns:Permission.type"/>
                        <xsd:element name="Delete" 
                                type="tns:Permission.type"/>
                        <xsd:element name="Execute" 
                                type="tns:Permission.type"/>
			<xsd:any namespace="##other" processContents="lax"/>
                </xsd:choice>
        </xsd:complexType>

Note that my previous posting, the schema fragment I used
is messed up. A corrected version follows:

        <xsd:element name="tns:Permissions" type="tns:Permissions.type"/>
        <xsd:complexType name="Permission.type">
                <xsd:simpleContent>
                        <xsd:restriction base="xsd:string">
                                <xsd:attribute name="type" 
                                        type="xsd:uriReference" use="default"
                                        value="http://saml.org/permissions"/>
                        </xsd:restriction>
        	</xsd:simpleContent>
	</xsd:complexType>
        <xsd:complexType name="Permissions.type">
                <xsd:sequence>
                        <xsd:element name="Permission" 
                                type="tns:Permission.type" 
                                maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:complexType>
Cheers,

Chris

christopher ferris wrote:
> 
> David,
> 
> The problem with use of namespaces in your example
> is that it means that the element with a local name
> of "permission" can take on completely different
> semantic meaning from one namespace to another.
> 
> If you wanted to, you could have something like
> the following:
> 
> <Permissions xmlns="http://saml.org">
>         <Permission>Read</Permission>
>         <Permission type="http://someextension.test">sss</Permission>
> </Permissions>
> 
> or, using namespace qualifier other than the default:
> 
> <saml:Permissions xmlns="http://saml.org">
>         <saml:Permission>READ</saml:Permission>
>         <saml:Permission saml:type="http://someextension.test">sss</saml:Permission>
> </saml:Permissions>
> 
> Both mean the same thing. The value of the type attribute could
> either be defaulted (in the schema) to "http://saml.org/permissions"
> or you could simply have it an implied value by virtue of
> the specification (e.g. specify that any Permission element
> without a 'saml:type' attribute MUST be considered as one
> of the set of permissions as defined by the SAML specification
> (READ, WRITE, etc).
> 
> The schema would look something like the following:
> 
>         <xsd:element name="tns:Permissions" type="tns:Permissions.type"/>
>         <xsd:complexType name="Permission.type">
>                 <xsd:simpleContent>
>                         <xsd:restriction base="xsd:string">
>                                 <xsd:attribute name="type"
>                                         type="xsd:uriReference" use="default"
>                                         value="http://saml.org/permissions"/>
>                         </xsd:restriction>
>         </xsd:simpleType>
>         <xsd:complexType name="Permissions.type">
>                 <xsd:sequence>
>                         <xsd:element name="Permission"
>                                 type="tns:Permission.type"
>                                 maxOccurs="unbounded"/>
>                 </xsd:sequence>
>         </xsd:complexType>
> 
> I'm uncomfortable with an element that contains a collection of
> values/tokens as in:
> 
> <permissions>READ WRITE DELETE sss</permissions>
> 
> because this must be further parsed using a tokenizer. We should
> endeavor to leverage XML (IMHO) as *the* parsing engine. Sure,
> it means a few more bytes for the additional angle-brackets and
> element names, etc. but in the long run, I think it is worthwhile
> to avoid imposing additional parsing overhead above and beyond
> what the XML parser is doing already. Since permissions
> 
> "Orchard, David" wrote:
> >
> > <snip/>
> >
> > > >
> > > > 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:
> > > <Permissions>
> > >       <Permission>Read</Permission>
> > >       <Permission>Write</Permission>
> > >       <Permission>Delete</Permission>
> > >       <Permission>http://someextension.test/sss</Permission>
> > > </Permissions>
> > >
> > > 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:
> > >
> > > <Permissions>
> > >       <Permission>http://saml.org/permissions/Read</Permission>
> > >       <Permission>http://saml.org/permissions/Write</Permission>
> > >       <Permission>http://saml.org/permissions/Delete</Permission>
> > >       <Permission>http://someextension.test/sss</Permission>
> > > </Permissions>
> > >
> > > 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:simpleType>
> > >         <xsd:complexType name="Permissions.type">
> > >                 <xsd:sequence>
> > >                         <xsd:element name="Permission"
> > >                               type="tns:Permission.type"
> > >                               maxOccurs="unbounded"/>
> > >                 </xsd:sequence>
> > >         </xsd:complexType>
> >
> > Seems to me that namespaces are a better way to differentiate between saml
> > and non-saml permissions.  In my proposal, I listed 5 ways that I had tried
> > to do this with schema.  This is on page 12.  As an aside, I probably should
> > add this style as well.
> >
> > My preference for permissions were one of the following
> >
> > 1. list of names,
> > <permissions>READ WRITE DELETE someext:sss</permissions> OR
> > <permissions>READ WRITE DELETE sss</permissions>
> >
> > This doesn't work because the enumeration value space can't be extended.
> >
> > 2. namespaced elements, ie
> > <Permissions>
> > <s0:Permission>W</s0:Permission>
> > <s1:Permission>Provision</s1:Permission>
> > I can't recall why this didn't work.
> >
> > Chris, any chance of you trying either of these methods?  I'm not a guru at
> > schema, so maybe I missed something.
> >
> > Cheers,
> > Dave
> >


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


Powered by eList eXpress LLC