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
