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

I'm running into what I think is a strange interpretation of the spec that 
IMHO in the most common
case will prevent streaming from being possible.

Looking at the 'with-option' spec, reguarding the select=XPathExpression.

-- quote
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.
--

If I read this right
So this means a simple example

   <p:with-option name="value" select="'string'"/>

Then a conformant processor needs to set the context for the xpath 
expression to the default readable port.
Similar with the convenience syntax say from your add-attribute-001 case

---
 <p:add-attribute match="title" attribute-name="foo" attribute-value="bar"/>

--- Expanes lexically to this
 <p:add-attribute>
  <p:with-option name="match" select="'title'" />
   <p:with-option name="attribute-name" select="'foo'" />
   <p:with-option name="attribute-value" select="'bar'"/>
</p:add-attribute>

------------
My interpretation of the spec is that all 3 implied <p:with-option> need to 
be supplied with the default readable port (stdin) as the context for each 
xpath expresion in turn ('title','too','bar') then supplied to the step 
itself.
In a practical way, this excludes any possibility of streaming (or at best 
requires a 4-way "tee").

For example,
Using Saxon, for the xpath I would need to read the input into document 
(XdmNode) and reuse it 4 times
Other possible implementations I'd have to read the source document into 
memory and provide it as a "source" 4 times.  Since there's no (practical) 
way using existing tools to pass the same "stream" (however thats 
implemented) to multiple instances of xproc evalutations without it being 
potentially consumed then copies *must* be made prior to evaluating the 
options.
If I am reading this right, I think this is major design flaw in the specs.
Now a simplistic implementation may already do that (pre-parse inputs into 
in-memory documents prior to executing), in which case its not an issue (for 
that imlementation).  But ideally, if I read the intent of the spec right, a 
sophisticated implementation shold be able to atleast attempt to implement 
some kind of streaming and with my interpretation of the spec here it cannot 
if any options are given to steps (which is almost all of them).

Suggestion #1 ...
One way of fixing this, IMHO, is  a tiny change in 4.8.1
This is by making the transformation

-------------- example
<ex:stepType>
  <p:with-option name="option-name" select="'some value'">    <p:empty/> 
</p:with-option>
</ex:stepType>

The second step uses the syntactic shortcut:
<ex:stepType option-name="some value"/>
--------------------------
That is, with the "syntactic shortcut" explicitly state that the xpath 
context the empty context,
not the default readable port.  I belive this is in line with the intent of 
the spec because the result
is limited to constant strings and therefore can never have any use of a 
context.

This is what I intend on doing in my implementation even if it makes it 
strictly non-conforming
(it wont be possible for an observer to tell).



Suggestion #2
More useful, IMHO, but more of a change ..

Make the default context for p:with-option itself default to the empty node, 
and add a syntax to force
it to be the default readable port if needed.

There are similar issues with other steps that take xproc expressions, but I 
think the with-option is the most common case because its most common use, 
IMHO, is to provide constant values, or to provide calculated values that 
are not depending on any context.


-----------------------------------------------------------
David A. Lee
dlee@calldei.com
http://www.calldei.com
http://www.xmlsh.org

Received on Sunday, 30 November 2008 13:40:42 UTC