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

One interesting data point
I looked at all the published "required" tests use of p:with-option
Not a single one of them used a context sensitive expression (out of 42 
p:with-option uses).
Atleast not that I could find.
May not be representive of real use cases, but its interesting, IMHO.

-David


>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.
>
> 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).
>
> 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 :)
>
> My argument is that when invoking an atomic step and passing it a context, 
> the intent of that step is to peform some kind of calcuation or 
> transformation on the input.  I belive that options passed to this 
> transformation would not likely be based on the context itself.  Otherwise 
> (as an author) I'd use a more complex transformation step in the first 
> place.
> e.g. if I call add-attribute its unlikly (in my mind) that a argument to 
> add-attribute would be based on the context itelf,
> or else I'd use  xpath or xslt or xquery instead where the context is 
> easily available and can be used directly as part of the step.  Or I'd 
> split it into 2 steps and assign the result of step 1 to a variable.
>
> 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.  To 
> me this seems like it entirely defeats the point of the word (and 
> philosophy) "Pipeline" at a core level.
>
> But I agree thats just an oppinion.
>
> Thanks !
>
> -David
>
> -----------------------------------------------------------
> David A. Lee
> dlee@calldei.com
> http://www.calldei.com

Received on Sunday, 30 November 2008 16:47:35 UTC