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