[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