- From: Erik Bruchez <erik@bruchez.org>
- Date: Wed, 30 Jan 2013 11:16:12 -0800
- To: Ulrich Nicolas Lissé <unlisse@gmail.com>
- Cc: Forms WG <public-forms@w3.org>
Uli, 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]) </function> 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. -Erik 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