RE: XPath on encoded SOAP documents

> 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.
> 
...
> 
> The dereferences introduced in XPath 2.0 cannot be used here 
> for three 
> reasons, of increasing complexity.
> 
> 1. href is not strictly speaking an ID
> 
> An href attribute that points to an element with id "a" has value 
> "#a".  This is a minor point, and requires only a minor adjustment.

This can be handled in XPath 1.0 by writing id(substring-after(@href, '#').
I don't think you need the XPath 2.0 dereference construct. (In fact, I'm
not convinced it's needed at all, since it only does a subset of what the
id() function does; but it has its fans).
> 
> 2. The element names in these documents are meaningless.
> 
> Dereferences use NameTests, just as axes do, which makes 
> sense when element 
> names are meaningful.

You can always use the wildcard "*" if you want a dereference where you
don't know the element name of the target.
 
> 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")

I expect you're aware that both XSLT 2.0 and XQuery 1.0 allow user-defined
functions to be used in XPath expressions. I expect other XPath hosts will
do the same.
> 
> But it gets ugly fast as the number of steps increases:
> 
>      href( href( href( n:getOrder, "n:order" ), Items)[1], shipToInfo)

XPath 2.0 allows a function call to appear as a step in a path, so you
should be able to write href(..)/href(..)/href(..)

> 
> This might be acceptable if all expressions are 
> computer-generated, but 
> definitely not otherwise.  XPath, rightly, expresses this 
> kind of iteration 
> with steps.  Accordingly, I added a new axis called "encoded-ref":
> 
> 	n:getOrder/encoded-ref::Items[1]/encoded-ref::shipToInfo

There's some logic in allowing user-defined axes; an axis is essentially
just a function that takes a single node as input and produces a sequence of
nodes as output. However, the general feeling especially in the XQuery group
is to use general-purpose functions rather than relying on the more
restricted axis concept.
> 
> and, since this became one of the most frequently used axes, 
> added the 
> abbreviation "^" :
> 
> 	n:getOrder/^Items[1]/^shipToInfo

Adding user-defined operators or abbreviations is definitely NOT something
we are contemplating! And my personal view is that your use case can be
handled adequately using user-defined functions, so there is no need to add
anything to the language.

Michael Kay
>

Received on Monday, 18 March 2002 06:57:26 UTC