W3C home > Mailing lists > Public > www-xpath-comments@w3.org > January to March 2002

Re: XPath on encoded SOAP documents

From: Michael Dyck <michaeldyck@shaw.ca>
Date: Sat, 16 Mar 2002 10:46:18 -0800
To: Mike Schilling <mschilling@edgility.com>
Cc: www-xpath-comments@w3.org
Message-id: <3C9392F9.981DBBE@shaw.ca>
Mike Schilling wrote:
> 
> Encoded SOAP documents (that is, XML documents that are generated by
> applying SOAP's encoding rules as described in
> http://www.w3.org/TR/soap12-part2/#soapenc) are a fast-growing segment
> of  XML .  Unfortunately, XPath is not well-equipped to process them.
> ...
>         <n:getOrderStatusResponse
>             xmlns:n='http://tempuri.org/OrderStatusTable'>
>           <Result href='#id0'/>
>         </n:getOrderStatusResponse>
> ...
>
> 2. The element names in these documents are meaningless.
> 
> Dereferences use NameTests, just as axes do, which makes sense when element
> names are meaningful.  In these documents, an expression like:
> 
>         n:getOrderStatusResponse/@Result #> id0
> 
> is useless.

I think you mean something more like
          n:getOrderStatusResponse/Result/@href=>id0
(is useless), right?

> It works on this particular document, but need not work on
> another document containing the same information created by a different
> implementation of the SOAP encoder.  A slight change to the data (e.g.
> adding a billTo address) could result in different element name even with
> the same encoder.  What's needed is a syntax which doesn't refer to the
> element name of the target.

A NameTest can be a Wildcard, so how about
          n:getOrderStatusResponse/Result/@href=>*
?

> 3. The structure of the document isn't entirely fixed.
> 
> ...
> Now what's needed is a construct which finds a child element and:
> 
>         If it's a real element, returns it.
> 
>         If it's a stub (has an href attribute), traverses its href link and
> returns the result.
> 
> The obvious way to extend XPath to handle this is to introduce a
> special-purpose function.  I actually did this (starting with standard
> Xalan 2.2), calling it "href".  This works reasonably well when only one
> link needs traversing:
> 
>         href(n:getOrderStatusResponse, "shipToInfo")

Doesn't this skip the 'Result' level?  Perhaps you mean
                href(n:getOrderStatusResponse, "Result")
or
          href( href(n:getOrderStatusResponse, "Result"), "shipToInfo" )

> But it gets ugly fast as the number of steps increases:
> 
>      href( href( href( n:getOrder, "n:order" ), Items)[1], shipToInfo)

Does Xalan let you write the function so that it operates on the context
node rather than arguments? Then your paths could look like:

      n:getOrderStatusResponse/Result/href()

      n:getOrderStatusResponse/Result/href()/shipToInfo/href()

      n:getOrder/Items[1]/href()/shipToInfo/href()

which isn't too ugly.

-Michael Dyck
Received on Saturday, 16 March 2002 13:48:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 3 October 2007 16:05:54 GMT