<function name="my:foo" as="number">
<param name="p" as="number"/>
<param name="q" as="number"/>
<sequence select="$p + $q"/>
</function>
Compact syntax introducing params
and select
attributes, with params
using the ParamList
construct from XQuery:
<function name="my:f" as="number" params="p as number, q as number" select="$p+$q"/>
Even more compact, suggested by @ebruchez syntax using part of the FunctionDecl
construct from XQuery:
<function signature="my:f(p as number, q as number) as number" select="$p+$q"/>
- Downsides:
- Marginally harder to parse.
- Less XMLish. (Which arguably, can be seen as an advantage.)
- Upside: compactness, obviously. This is particularly important as this construct would often be used to avoid code duplication by moving a common sub-expression into a function. If the syntax to declare a function is too cumbersome, some will judge the remedy to be worse than desease.
I also misread that part of the XPath spec. I can't imagine that supporting the context, in addition to variables, adds significant complexity to an implementation. So their decision must have been motivated by other reasons, which aren't clear to me. But this being the way functions are defined in XPath 3.0, I agree it isn't unreasonable to follow XPath's footsteps, even if we wouldn't have made the same choice. And as you've shown in the above example, this isn't a show-stopper.