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


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