RE: variables in xPath statements

OK, so my next attempt... :)

For p:option/@select, the XProc spec says that: "the [XPath] variable
bindings consist only of bindings for options whose declaration precedes
the p:option itself in the surrounding step signature". However, it is
does not say the same about p:variable, and the definition of the
inherited environment is also very revealing in this case. So it is not
clear to me whether this is allowed or not in XProc:

 

<p:variable name="x" select="'foo'"/>

<p:variable name="y" select="$x"/>

 

It seems that Calabash does not support this, but Calumet (our XProc
impl) does... I am not sure who is wrong here - perhaps the spec itself?

 

As a workaround for Calabash, I suggest trying the following:

 

<p:for-each name="forEachChunk">

  <p:variable name="divID" select="/*/@id"/>

  <p:group>

    <p:variable name="ancestorID"
select="//div[@id=$divID]/ancestor::chapter[1]/@id">

      <p:pipe port=result" step="loadDocument"/>

    </p:variable>

    <p:wrap name="wrapChunks" wrapper="doc" match="/*"/>

    ...

  </p:group>

<p:for-each>

 

Regards,

Vojtech

 

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

 

From: yamahito [mailto:yamahito@gmail.com] 
Sent: Monday, June 21, 2010 3:31 PM
To: Toman, Vojtech
Cc: xproc-dev@w3.org
Subject: Re: variables in xPath statements

 

Hi Vojtech

Well spotted!  However, I don't think this is the primary error (I
should have posted this first):

Severity: error
Description: XD0023 : Undeclared variable in XPath expression: $divID It
is a dynamic error if an XPath expression is encountered which cannot be
evaluated (because it is syntactically incorrect, contains references to
unbound variables or unknown functions, or for any other reason).
URL: http://www.w3.org/TR/xproc/#err.D0023

Sorry to keep shooting down your suggestions, I'm very grateful for your
input and prompt replies so far!

Thanks,
Tom

On 21 June 2010 09:16, <Toman_Vojtech@emc.com> wrote:

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