- From: <Toman_Vojtech@emc.com>
- Date: Tue, 9 Dec 2008 07:26:47 -0500
- To: <xproc-dev@w3.org>
Hi all, The pipeline does not work the way Raymond supposed it to. Each p:with-option is evaluated only *once* (just before the processor executes the step), and the resulting option bindings are then made available to the step. So, in our case, the "attribute-value" option will be bound to "section_1" and this value will/can never change inside the p:add-attribute step. Therefore, the result will be something like: <html> <head> <title>Topic 01</title> </head> <body> <h1>Topic 01</h1> <div class="section" id="section_1"> <h2>T01 - Section 1</h2> <p>Content 01</p> </div> <div class="section" id="section_1"> <h2>T01 - Section 2</h2> <p>Content 02</p> </div> <div class="section" id="section_1"> <h2>T01 - Section 3</h2> <p>Content 03</p> </div> </body> </html> Regards, Vojtech > -----Original Message----- > From: James Fuller [mailto:james.fuller.2007@gmail.com] > Sent: Tuesday, December 09, 2008 1:13 PM > To: David A. Lee > Cc: Raymond Bissonnette; Toman, Vojtech; xproc-dev@w3.org > Subject: Re: with-option and other XPath Expressions - > Prevent streaming from being possible (??) > > ah ... I see where I am getting confused ... your thread and > Raymonds... let me see if I can be 'clear' > > the > > p:add-attribute match="//div[@class='section']" attribute > operates on the default readable port > > and > > the select="concat('section_',position())" attribute > operates on what is matched > > the behavior of the p:with-option select for attribute-value is > defined by the p:add-attribute step text > > 'The p:add-attribute step adds a single attribute to a set of matching > elements. The input document specified on the source is processed for > matches specified by the match pattern in the match option. For each > of these matches, the attribute whose name is specified by the > attribute-name option is set to the attribute value specified by the > attribute-value option.' > > that being said the pipeline will not work because both options > attribute-name and attribute value are required. > > there maybe some holes in the spec here, but I think its probably > undergone this level of scrutiny ... will have a check once I have a > bit more time. > > hth, Jim Fuller > On Tue, Dec 9, 2008 at 12:47 PM, David A. Lee > <dlee@calldei.com> wrote: > > Jim, by saying this is clear to you (it is to me). > > Are we seeing the same 'clear'? > > > > That is, the example given in this thread would NOT work as given. > > That is, the select expression would NOT be executed in the > context of each > > opperation, > > it would be executed ONCE given the default input port as > its context > > (NOT each node as add-attribute executes). > > > > Is that the same "clear" your reading ? > > > > > > Thanks > > > > > > > > > > > >> > >> On Tue, Dec 9, 2008 at 12:37 PM, David A. Lee > <dlee@calldei.com> wrote: > >>> > >>> This puts an entirely different interpretation on the > spec then I have in > >>> my > >>> mind. > >>> To my reading, this behaviour implies that the select= option of a > >>> with-option > >>> not only has access to and reads from the default input port, > >>> but must execute within the same context as the step > while the step runs > >>> ! > >>> > >> > >> one moment, I didnt validate *what* you were saying .... > or commenting > >> on if this xproc even runs ... it seemed like you were > more asking a > >> question about submitting a test case. > >> > >>> There's nothing in the spec that says this. Should it ? > >>> Thats a very different interpretation then I had. > >>> Reading the spec I interpret to mean like this > >>> > >>> For every with-option > >>> execute the select= expression > >>> gather the result > >> > >> in section 5.7.3 p:with-option it says; > >> > >> 'All in-scope bindings for the step instance itself are > present in the > >> Processor XPath Context as variable bindings, so select expressions > >> may refer to any option or variable bound in those > in-scope bindings > >> by variable reference. If a variable reference uses a QName that is > >> not the name of an in-scope binding or preceding sibling option, an > >> XPath evaluation error will occur. > >> > >> If a select expression is used but no document binding is provided, > >> the implicit binding is to the default readable port. It > is a static > >> error (err:XS0032) if no document binding is provided and > the default > >> readable port is undefined. It is a dynamic error (err:XD0008) if a > >> document sequence is specified in the binding for a > p:with-option. In > >> an XPath 1.0 implementation, if p:empty is given as the document > >> binding, an empty document node is used as the context node. In an > >> XPath 2.0 implementation, the context item is undefined.' > >> > >> is a clear definition to me. > >> > >> Jim Fuller > >> > > > > > >
Received on Tuesday, 9 December 2008 12:27:47 UTC