Re: Custom XPath Functions feature page updated


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])"/>

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))"/>


On Wed, Aug 12, 2009 at 3:18 PM, John Boyer<> 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:
> Blog:
> Blog RSS feed:

Received on Thursday, 13 August 2009 02:58:36 UTC