- From: David A. Lee <dlee@calldei.com>
- Date: Tue, 9 Dec 2008 06:37:12 -0500
- To: "James Fuller" <james.fuller.2007@gmail.com>, "Raymond Bissonnette" <raybiss@formedia.ca>
- Cc: <Toman_Vojtech@emc.com>, <xproc-dev@w3.org>
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 ! 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 Pass the evaluated values of the options to the step Step processes the action given a copy of the options. This acts more like a traditional 'function call' where the arguments are evaluated prior to calling a function. That is the interpretation I have from the spec. But looking at this example, obviously some other meaning was implied. The spec currently says that the with-option has its context set to the default readable port. It does NOT say the context is set to each element in turn which add-attribute operates on while its executing. The example seems to run with this implementation Run the step For every node where the step would perform an action Re-evaluate the with-option setting that node as the context For add-attribute I can imagine this might work (as below sample) But can this work for every possible action ? If this is the intended behaviour I think it brings up a whole new magnitude of potential implementation defined behaviour. Not only do the standard steps have to say what the black-box behaviour is but also have to define HOW they do it to a much more fine degree of specification (and hence binding to implementation). In the above example the add-attribute step would have to have added to it that the action must explicitly set the context to the currently matched node prior executing the select expression. In turn every single standard library action will have to have its specs updated to indicate at what point exactly the with-options are executed and what their context will be exactly at that point. (possibly with different options behaving differently) I think that adds a very slippery slope and complicates the spec by 10fold, as well as forcing implementations not only to implement all the standard actions but to do so in exactly the same way. If this is really what the intent is, then the spec needs a LOT more work, and I'm likely to abandon my attempt at implementing it. This whole problem could be 'solved' by saying with-options are bound to the empty port, or an explicitly defined port ... of course that means this particular case cant be implemented in 1 step. Either that or theres a LOT more work to be done on the spec. > might be good to amend source to have a more complete test. > > <html> > <head> > <title>Topic 01</title> > </head> > <body> > <h1>Topic 01</h1> > <div class="header"> > <div>some other div content</div> > </div> > <div class="section"> > <h2>T01 - Section 1</h2> > <p>Content 01</p> > </div> > <div class="section"> > <h2>T01 - Section 2</h2> > <p>Content 02</p> > </div> > <div class="section"> > <h2>T01 - Section 3</h2> > <p>Content 03</p> > </div> > </body> > </html> > > otherwise great to receive more tests .. I would say > http://tests.xproc.org/contact/ > > cheers, Jim Fuller > On Tue, Dec 9, 2008 at 1:15 AM, Raymond Bissonnette <raybiss@formedia.ca> > wrote: >> >> Hi, >> >> I'm a bit of a newbie with XProc and I just started looking at >> p:with-option >> yesterday. The following pipeline might represent a simple test case. >> >> <p:pipeline> >> <!-- use the default input source --> >> <p:add-attribute match="//div[@class='section']" attribute-name="id" > >> <p:with-option name="attribute-value" select="concat('section_', >> position())"/> >> </p:add-attribute> >> </p:pipeline> >> >> With this source: >> >> <html> >> <head> >> <title>Topic 01</title> >> </head> >> <body> >> <h1>Topic 01</h1> >> <div class="section"> >> <h2>T01 - Section 1</h2> >> <p>Content 01</p> >> </div> >> <div class="section"> >> <h2>T01 - Section 2</h2> >> <p>Content 02</p> >> </div> >> <div class="section"> >> <h2>T01 - Section 3</h2> >> <p>Content 03</p> >> </div> >> </body> >> </html> >> >> Expecting this result: >> >> <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_2"> >> <h2>T01 - Section 2</h2> >> <p>Content 02</p> >> </div> >> <div class="section" id="section_3"> >> <h2>T01 - Section 3</h2> >> <p>Content 03</p> >> </div> >> </body> >> </html> >> >> I'm not there yet but I understand the spec better every day. Thanks in >> great part to this list. >> >> The above was inspired by looking at add-attribute-002.xml, so maybe it >> could become add-attribute-003.xml. >> >> >> Regards, >> Raymond >> >> -----Original Message----- >> From: xproc-dev-request@w3.org [mailto:xproc-dev-request@w3.org] On >> Behalf >> Of Toman_Vojtech@emc.com >> Sent: Monday, December 08, 2008 9:38 AM >> To: xproc-dev@w3.org >> Subject: RE: with-option and other XPath Expressions - Prevent streaming >> from being possible (??) >> >> >>> One interesting data point >>> I looked at all the published "required" tests use of p:with-option >>> Not a single one of them used a context sensitive expression >>> (out of 42 >>> p:with-option uses). >>> Atleast not that I could find. >> >> By the way, there are a couple of recent tests that do this now: >> base-uri-001.xml >> base-uri-002.xml >> preserve-base-uri-001.xml >> >> I agree, it may not be convincing at all, but at least have some tests >> that use context sensitive p:with-option. And I am sure we will have >> more (as a matter of fact, I am writing one myself at the moment :) >> >> Regards, >> Vojtech >> >> >> >> >> >
Received on Tuesday, 9 December 2008 11:37:56 UTC