- From: <Toman_Vojtech@emc.com>
- Date: Tue, 22 Jun 2010 03:15:32 -0400
- To: <xproc-dev@w3.org>
- Message-ID: <997C307BEB90984EBE935699389EC41C01B17A6F@CORPUSMX70C.corp.emc.com>
Just final clarification. The following: <p:variable name="x" select="'foo'"/> <p:variable name="y" select="$x"/> should work because of section 5.7.1 (p:variable) in the specification: "If a select expression is given, it is evaluated as an XPath expression using the appropriate context as described in Section 2.6, "XPaths in XProc", for the enclosing container, with the addition of bindings for all preceding-sibling p:variable and p:option elements." Thanks to Norm for pointing that out to me. 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 Toman_Vojtech@emc.com Sent: Monday, June 21, 2010 3:51 PM To: xproc-dev@w3.org Subject: 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('&', $ancestorID, '&')"> <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
Received on Tuesday, 22 June 2010 07:16:12 UTC