Re: New static error: options in the XProc namespace

On 5/11/07, Norman Walsh <ndw@nwalsh.com> wrote:
> One consequence of using variables instead of functions for the state
> information ($p:episode and friends) is that they potentially conflict
> with the names of options.

I have seen that there was a straw poll during the last call which got
us 2 for functions against 3 for variables and 1 abstention. I
understand the need for making progress, but it looks like we have not
reached a consensus on this one. Looking at the arguments on each
side:

(V) For variables: (1) With some XPath APIs, hooking a function
handler is more complex than passing the value of a variable.

(F) For functions: (1) Extending XPath with function done more
frequently in W3C standards (e.g. XSLT, XForms). (2) Unless the API
provides a way to pass a call-back to get the value of a variable,
using variable might be less efficient in the cases where there are a
number of variables to declare, as a structure with the name and value
for each variable will need to be passed. (3) Like Norm noted, there
is a potential conflict with pipeline state variables which means we
need to create an additional rule to prevent the conflict.

My bias: with all the XPath API I used so far (jaxen, Saxon, JAXP),
declaring a function or a variable is of equal complexity. So I
haven't experimented (V1), and this only leaves me with arguments for
functions.

Is this all there is? Are there other reasons we want to use variables
when others use functions?

Alex
-- 
Orbeon Forms - Web 2.0 Forms for the Enterprise
http://www.orbeon.com/

Received on Friday, 11 May 2007 17:27:55 UTC