W3C home > Mailing lists > Public > public-forms@w3.org > January 2013

Re: XForms 2.0 Draft review: The function Element

From: Erik Bruchez <erik@bruchez.org>
Date: Wed, 30 Jan 2013 11:16:12 -0800
Message-ID: <CAAc0PEVGNpBr3ZrZ6K2H+11_=prPO89PF0EHvQ=J=P4+9GcMpQ@mail.gmail.com>
To: Ulrich Nicolas Lissť <unlisse@gmail.com>
Cc: Forms WG <public-forms@w3.org>

I think we should keep the feature but make sure it is simple enough.

Not having any reuse of XPath expressions in XForms is an immense
pain, not even considering that it's disastrous in 2013 to have an
expression language but no way to define functions (and programming is
largely about functions). Even XSLT 2.0 (finalized more than 6 years
ago!) realized that and added support for xsl:function.

This said, the feature is in fact fairly simple, but is currently
specified in a way that make it look too complex. I suggested in the
past dropping *all* nested elements and just leaving the body of
xf:function as, well, the body of the function. So:

<function signature="my:sumproduct($p as xs:decimal*, $q as
xs:decimal*) as xs:decimal">
   sum(for $i in 1 to count($p) return $p[$i]*$q[$i])

So no nested var, sequence, or script elements. For local variables,
it's a shame, but that's really saying more about bad design decisions
in XPath 2 than anything else (they included "let" for local variables
in XQuery 1.0, but not in XPath 2.0). I don't think we need to go out
of our way in XForms to fix this, given that XPath 3.0 will have
"let". Also, you could use JavaScript or another language if you need
more expressive power.

In this proposal, the @type attribute must be moved to the xf:function
element. I suggest specifying shortcuts for @type, as in HTML:
type="javascript", type="xpath".

I don't have a strong opinion about whether xf:function should be in
the core of the spec or in the XPath module.


On Tue, Jan 29, 2013 at 12:10 PM, Ulrich Nicolas Lissť
<unlisse@gmail.com> wrote:
> Dear Group,
> I'm in favor of dropping
> http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#The_function_Element
> entirely. While I can image some use cases for the function Element
> and appreciate all the effort you put into this, I think its
> disadvantages by far outweigh its utility:
> - increases complexity of XForms
> - seems hard to implement
> - script integration is sketchy
> - adds another hard dependency to XPath (in contrast to transfer XPath
> integration to an own module)
> If at all, the function Element should be made optional and moved to
> the XPath Expressions Module.
> Regards,
> Uli.
> --
> Ulrich Nicolas Lissť
Received on Wednesday, 30 January 2013 19:16:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:07 UTC