RE: with-option and other XPath Expressions - Prevent streaming from being possible (??)

Hi,

I'm sorry about the confusion but happy to learn my interpretation was wrong
because this was becoming a lot more difficult to implement.

I'm learning a lot from the existing test case files but (as you can see) I
also still have many dots to connect.


Best regards,
Raymond



-----Original Message-----
From: xproc-dev-request@w3.org [mailto:xproc-dev-request@w3.org] On Behalf
Of Toman_Vojtech@emc.com
Sent: Tuesday, December 09, 2008 7:27 AM
To: xproc-dev@w3.org
Subject: RE: with-option and other XPath Expressions - Prevent streaming
from being possible (??)


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 22:44:23 UTC