RE: variables in xPath statements

Of course I didn't notice - thanks for reminding me :) The problem is
with p:string-replace:

 

<p:string-replace name="completeMeta" match="//ancestorID/text()"
replace="string($ancestorID)"/>

 

This is not correct, because if you look at the documentation of
p:string-replace step, the value of the "replace" option is an XPath
expression. This expression will be evaluated by the step (which, aside
from a number of exceptions, does not see any XPath variables - see the
description of the Step XPath context in the spec). Therefore the
expression:

 

string($ancestorID)

 

cannot be evaluated by the step.

 

What you want is this:

 

<p:string-replace name="completeMeta" match="//ancestorID/text()">

  <p:with-option name="replace" select="concat('&amp;', $ancestorID,
'&amp;')">

    <p:empty/>

  </p:with-option>

</p:string-replace>

 

 

Regards,

Vojtech

 

--
Vojtech Toman
Principal Software Engineer
EMC Corporation
toman_vojtech@emc.com
http://developer.emc.com/xmltech

 

From: xproc-dev-request@w3.org [mailto:xproc-dev-request@w3.org] On
Behalf Of yamahito
Sent: Monday, June 21, 2010 3:02 PM
To: xproc-dev@w3.org
Subject: Re: variables in xPath statements

 

Hi Vojtech,

Did you notice that the ancestorID variable is using the result port of
the loadDocument step?  I'm wanting it to go and look at the original
source document rather than the 'chunk' for precisely the reasons you
give here - or is there another reason that wouldn't work?

Tom

On 21 June 2010 08:52, <Toman_Vojtech@emc.com> wrote:

> <p:filter select="//div">
>       <p:input port="source">
>               <p:pipe port="result" step="loadDocument"/>
>       </p:input>
> </p:filter>
>
> <p:for-each name="forEachChunk">
>
>       <p:variable name="divID" select="/*/@id"/>
>       <p:variable name="ancestorID"
> select="//div[@id=$divID]/ancestor::chapter[1]/@id">
>               <p:pipe port=result" step="loadDocument"/>
>       </p:variable>

In XProc, the data that you process is always XML documents. That means
that if you, for instance, use p:filter (or p:input/@select) to extract
parts of a document, the result you get is always a sequence of
*documents*.  This is why I think the XPath expression for ancestorID
fails: "div" is the document element, and therefore there is no ancestor
"chapter" element.

Hope this helps,
Vojtech

--
Vojtech Toman
Principal Software Engineer
EMC Corporation
toman_vojtech@emc.com
http://developer.emc.com/xmltech