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

My reading of both the specs and your email here conclude something 
different then

-- quote
"the select="concat('section_',position())" attribute
operates on what is matched"
---

There's nothing in the add-attribute that says the select value "operates on 
what is matched"
Rather it seems 'clear' to me that the value of select= is evaluated with 
the input port
as its context (implying the document node) NOT with the node that the 
match.

But I do agree somewhat with the last comment:

> that being said the pipeline will not work because both options
> attribute-name and attribute value are required.

Its not so much (IMHO) that they are 'required' though ... even if they are 
option the same behaviour would occur.

I think this is a major, not trivial, distinction.

with-option and with-param values are calculated with the default input port 
as their context,
implying the document node.  Also implying they should be (or atleast act as 
if they were) calculated prior to invoking the step.   Not re-executed 
within the step (atleast at any point not the document root of the input).

If this is not a correct interpretation, I'd love some help understanding.

Thank you
-David




----- Original Message ----- 
From: "James Fuller" <james.fuller.2007@gmail.com>
To: "David A. Lee" <dlee@calldei.com>
Cc: "Raymond Bissonnette" <raybiss@formedia.ca>; <Toman_Vojtech@emc.com>; 
<xproc-dev@w3.org>
Sent: Tuesday, December 09, 2008 7:12 AM
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:30:37 UTC