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

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:14:03 UTC