Re: Custom XPath Functions feature page updated

Hi Erik,

Actually, the concern about the variable usage was yours (in prior version 
of the wiki page) because the examples were written exactly as shown, 
except that they were using variables that were being changed by xforms 
actions.

You used recursion in your sumproduct, which could have also been done 
with the local instance version.  Didn't do it that way though because it 
would be fairly inefficient.

Overall I like the variable version better, esp. as you have now removed 
the need, at least from the examples, of the need to mutate the variables. 
 However, I am wondering if we will be able to stay away from using xforms 
actions altogether, or if the feature will be too limited without them.

If we are able to run xforms actions, then the problem arises that the 
variables may be immutable, but the nodes to which they point are not. 

The local instance data design avoids adding a function mechanism that 
enables the function to perform data mutations while running. 

But perhaps we could say that the nodeset parameters receive copies of the 
nodes from data sent as parameters in the invocation.  So, if you change 
them, the function still is not creating side effects.  In other words, 
pass by value not by reference.  What do you think of that option?

John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





From:
Erik Bruchez <ebruchez@orbeon.com>
To:
public-forms@w3.org
Date:
08/12/2009 07:58 PM
Subject:
Re: Custom XPath Functions feature page updated



John,

A few (mostly disagreeing) comments on this:

1. Variables vs. local instances

I am not sure why or to whom it was a concern that we used variables,
which we want to have anyway and which are the number one construct I
would like to see in XForms 1.2!

A case can certainly be made that we need local instances (or even
models). I think this should be considered an option but but not a
requirement for local data.

As is the new examples look terrible to me: they combine a heavy
syntax and an error-prone system to references the data. Variables fix
both these issues.

In cases where variables are "constant" (i.e. they are evaluated once
only in a given execution, as is the case in XSLT and XQuery), the
XPath variable notation is in my opinion clearly superior to pointing
to a local data model. In particular it removes confusion about XPath
context resolution and allows the XForms processor to do better static
checking that the expressions are correct.

I have added by own version of the examples on the wiki page. You can
compare, in particular, the difference in the weight of the syntax for
the dollar-round example in particular.

2. Reference to function parameters

The examples currently don't use the XPath variable notation to refer
to the function parameters. But I don't see how you would reconcile 1)
the default evaluation context which seems to be the root element of
the local instance with 2) references to the function parameters.

Using the variable notation is the best way I think of accessing the
function parameters by name, and that syntax will be instantly
familiar to XSLT/XQuery authors.

3. Imperative vs. funtional style

The current sumproduct example is written in what we could call
"extreme imperative style". Compare with the following pure functional
version, which:

* is much shorter
* doesn't require a local instance
* remains easy to understand
* can be run as fast if not faster by a smart processor (tail recursion)

<function name="my:sumproduct" as="number">
   <param name="p" as="nodeset"/>
   <param name="q" as="nodeset"/>

   <return if="count($p) = 0 or count($p) != count($q)" value="0"/>
   <return if="count($p) > 0" value="$p[1] * $q[1] +
my:sumproduct($p[position() > 1], $q[position() > 1])"/>
</function>

Note that to make it even better an actual if/else construct would be
desireable. In XPath 2.0, you could also write:

<function name="my:sumproduct" as="xs:decimal">
   <param name="p" as="xs:decimal*"/>
   <param name="q" as="xs:decimal*"/>

   <return value="if (count($p) = 0 or count($p) != count($q)) then 0
                     else $p[1] * $q[1] +
my:sumproduct(subsequence($p, 2), subsequence($q, 2))"/>
</function>

-Erik

On Wed, Aug 12, 2009 at 3:18 PM, John Boyer<boyerj@ca.ibm.com> wrote:
>
> I've done an updated draft of the Custom XPath Functions feature, for
> possible inclusion in XForms 1.2.
> The prior page had not been updated in a long time, but there were a lot 
of
> concerns about it because it was based on creating XPath variables. 
 This
> version eliminates variables in favor of an internal instance.
> It comes out a lot cleaner this way, and it also enabled me to easily 
solve
> pretty much all of the related problems we were having.  It is, at 
least, a
> better "strawman" worth further discussion.
>
> It would be very powerful to have this extension mechanism as a way to
> enable authors to create more powerful forms that work across
> implementations.
>
> Cheers,
> John M. Boyer, Ph.D.
> STSM, Interactive Documents and Web 2.0 Applications
> Chair, W3C Forms Working Group
> Workplace, Portal and Collaboration Software
> IBM Victoria Software Lab
> E-Mail: boyerj@ca.ibm.com
>
> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
> Blog RSS feed:
> http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw
>
>