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] | [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]