Re: XPath on encoded SOAP documents

Message-ID: <DFF2AC9E3583D511A21F0008C7E6210602679CCE@daemsg02.software-ag.de>
From: "Kay, Michael" <Michael.Kay@softwareag.com>
To: "'Mike Schilling'" <mschilling@edgility.com>, www-xpath-comments@w3.org
Date: Mon, 18 Mar 2002 12:57:19 +0100
Subject: RE: XPath on encoded SOAP documents

 > 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.


As does XPath 1.0, unless I'm misinterpreting:

         This document defines a core function library that all XPath 
implementations must support (see [4 Core Function
         Library]). For a function in the core function library, arguments 
and result are of the four basic types. Both XSLT
         and XPointer extend XPath by defining additional functions; some 
of these functions operate on the four basic
         types; others operate on additional data types defined by XSLT and 
XPointer.

 > > 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(..)


Thanks; this is the point I had missed about General Steps.  It's an 
extension of XPath 1.0, in which function calls could only appear as the 
first step in a path.

      [19]    PathExpr     ::=          LocationPath
                                                | FilterExpr
                                                | FilterExpr '/' 
RelativeLocationPath
                                                | FilterExpr '//' 
RelativeLocationPath


This does solve the problem with acceptable syntax.

As SOAP use is growing by leaps and bounds, and the encoded format is 
currently the more popular of the two, I suggest you consider adding such a 
function to the standard.  It adds almost nothing to the cost of 
implementing XPath.

Received on Tuesday, 26 March 2002 17:06:06 UTC