[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] In defence of XPath
Cameron Morris wrote on 6/2/2005, 12:35 PM: > I must not be understanding your proposal correctly. I thought you > wanted to change how the attributes are named, by schema namespace > instead of by XPath. I see no difference between the values within the > attributes. Perhaps an example query and resulting attribute statement > would would help. > > Here is an example of how I understand your proposal: > Example XML document for John Doe: > <sample:body xmlns:sample="urn:saml:xpath:sample"> > <sample:foo> > <sample:bar name="sample element1">value1</sample:bar> > </sample:foo> > <sample:foo> > <sample:bar name="sample element2">value2</sample:bar> > </sample:foo> > </sample:body> Let's use a real example as that seems way to contrived for me as some set of name-value pairs that wouldn't be a typical XML document for data. How about we have a document like: <profile> <name lastUpdate="10/1/03">Conor</name> <address> <addr1>10 main street</addr1> <addr2>apt. 999 </addr2> <city>somewhere</city> <st>SP</st> <zip>99999</zip> </address> <phone class="home">999-999-9999</phone> <phone class="cell">888-888-8888</cell> </profile> To reeturn the name and phone numbers with an assertion, I propose we include the following as an attribute statement: <Attribute name="profile" ... > <AttributeValue> <profile> <name lastUpdate="10/1/03">Conor</name> <phone class="home">999-999-9999</phone> <phone class="cell">888-888-8888</cell> </profile> </AttributeValue> </Attribute> While in your proposal it would look something like: <Attribute name=[xpath to name] ... > <AttributeValue> Conor </AttributeValue> </Attribute> <Attribute name=[xpath to phone] ... > <AttributeValue>999-999-9999</AttributeValue> </Attribute> <Attribute name=[xpath to phone] ... > <AttributeValue>888-888-888</AttributeValue> </Attribute> The differences (and, I believe, advantages of the first proposal above) are: * The data within the <AttributeValue> container is in the *exact* format one would expect from interacting with the service. With the Xpath solution, the recipient must put together the xpath data plus the data within the Attribute value to essentially reverse engineer the document structure -- and to fully understand the element you have to understand the placement of the element within the document structure. * Attributes on elements within the source document are not easily handled (as far as I can tell) with the proposed solution (where does the lastUpdate attribute end up for the name element, likewise the class for the phone element. * the xpath solution assumes that the source document is xpath addressable (that that's the structure used by the service) and locks itself to that type of service I think there are very strong benefits of using the non-xpath model that make it much more useful in a wider variety of scenarios. Conor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]