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:13:25 UTC