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

"David A. Lee" <dlee@calldei.com> writes:
> 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.

That sounds perfectly reasonable to me.

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

Here we wind up with a qualitative rather than quantitative decision,
so it's harder to make.

You're asserting that this kind of expression (one that doesn't depend
on the context):

  <p:with-option name="optname" value="concat('X-',$var)"/>

is going to be more common than this type (which does):

  <p:with-option name="optname" value="concat('X-',/path/to/elem)"/>

First, I'm not sure you're right. But even if you are: the current
rules place the burden on the implementor in the default case. Your
proposed change places the burden on the user. He or she has to
remember to make an explicit binding everytime they write an XPath
expression that depends on the context, even when the context is the
default readable port.

Given that a user can explicilty require forking the default readable
port, so that implmentors must handle that case, I don't see the harm
in letting that case arise by default occasionally.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | It only takes 20 years for a liberal to
http://nwalsh.com/            | become a conservative without changing
                              | a single idea.--Robert Anton Wilson