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
>
