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

"David A. Lee" <dlee@calldei.com> writes:
> I agree with your logic up to the last point
>
> --- NW quoteth
> 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.
> ---
>
> The issue I raise is not whether the implemention must support forking
> (it obviously does as you mention)
> But rather if xproc can be reasonably implemented is as many cases as
> "reasonable" without forking.
>
> You are right that to improve this (except in the first case which you
> agreed with )  that shifts the the burden from the implementation to
> the user.  I agree with that and obvious there are different oppinions
> on if this is "best".  But it has nothing at all to do with if the
> implementation has to support forking,
> it has to do with the more subtle detail of when it can be avoided.
> With some kind of "hint" in the syntax
> that would be a lot easier to implement what I suspect (but obviously
> cant prove) will be a majority of the cases.
>
> But I do agree this is a judment call.   There appear to be 2 goals
> that cant always be resolved in both's favor all the time.
>
> * the syntax should be as simple as possible for the author
> * the implementation should able to be as efficient as possible
>
> I agrue that there should be a syntax to specify an xpath expression
> with no (or empty) context.

There is, put <p:empty/> in the context.

> The syntax itself need not be more complex to support that (it could
> be as simple as    select_nocontext="foo" ,
> or alternatively select_withcontext="/" for the context case ) but of
> course it does makes the spec more complex (by adding more
> attributes).

At the moment,

  <p:option name="foo" select="some-expression"/>

requires a binding and binds to the default readable port if you don't
provide an explicit binding. At the same time,

  <p:option name="foo" select="some-expression">
    <p:empty/>
  </p:option>

explicitly identifies the option as one which does not require a binding.

So, syntactically, we have all that we need. I think it's a judgement
call (and I'm wavering about it myself, as I gain experience writing
"real" pipelines) whether to go with the status quo or to change the
status quo so that

  <p:option name="foo" select="some-expression"/>

always has an empty binding and users have to say this:

  <p:option name="foo" select="some-expression">
    <p:pipe step="something" port="somethingelse"/>
  </p:option>

if they want a binding.

I'm strongly opposed (on both technical and aesthetic grounds) to
adding a new bit of syntax as you propose above.

> My personal oppinion is that atleast in with-option (and possibly
> others) the no-context case should be the default case, but of course
> I cant support that oppinion without the entire copus of xproc
> programs yet to  be written :)

Right. And we both agree it's a judgement call. I think, on balance,
the status quo is better than flipping it, but it's not overwhelmingly
obvious which answer is the right one.

Both approaches leave the pipeline author in the position of having to
do some extra work some times.

So, when I have to introduce an explicit binding, being able to say
<p:empty/> strikes me as slightly better than having to make the
p:pipe explicit (which might also require me to add a name to the
preceding step).

> The way it stands now, every step in a pipeline that has an explicit
> option *requires* copying/forking of the input even if its never used.

That's not strictly true. I think it's important to remember that
implementations have some freedom here. Let's say we stick with the
status quo, there's nothing that prevents an implementation from doing
static analysis on the XPath expression and determining that it does
not use the context. Then it can skip the fork even when a more naive
implementation would fork.

I'm tempted to do a little bit of this myself. Just recognizing the
expressions ^\$[A-Za-z_][A-Za-z0-9_]$, ^\'.*\'$, and ^\".*\"$ would
probably cover 80% of the cases. (It wouldn't obviate the user from
providing the explicit binding, however.)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The universe that we observe has
http://nwalsh.com/            | precisely the properties we should
                              | expect if there is, at bottom, no
                              | design, no purpose, no evil and no
                              | good, nothing but pitiless
                              | indifference.--Richard Dawkins