- From: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
- Date: Thu, 22 Nov 2012 12:43:05 +0000
- To: Public Forms <public-forms@w3.org>
- Message-ID: <18F2D59C-3E43-4D46-8FFC-991B8B09D85E@inventivegroup.com>
All, When the function[1] element was reviewed by the working group early this year. Some people felt that the syntax was too heavy. To refresh your memory this is the current syntax: <function signature="my:sumproduct($p as xs:decimal*, $q as xs:decimal*) as xs:decimal"> <sequence value="sum(for $i in 1 to count($p) return $p[$i]*$q[$i])"/> </function> Some people wanted a value attribute on the function element, and if you wanted to use nested content that you could drop the sequence element (or script if you are using a scripted implementation for the custom function). I'm not completely sure if the value attribute is going to be used that much, because you probably are going to have a couple of variable declarations inside the function definition to make the body readable. It is only in rare cases that the function body is going to be that simple that you want to write its implementation in one simple expression I think. For the XPath as the content of an element. I'm not a big fan of that, because we have never done this in the spec and it makes reading formatting the document harder if you are interleaving variable definitions and XPath expression. And it will mean that all script attributes (e.g.: selecting the scripting language) will go on the function element and only make sense if you are using a script implementation. Please send in your thoughts related to these two open issues related to the function element. Kind regards, Nick Van den Bleeken R&D Manager Phone: +32 3 425 41 02 Office fax: +32 3 821 01 71 nick.van.den.bleeken@inventivegroup.com<mailto:nick.van.den.bleeken@inventivegroup.com> www.inventivedesigners.com 1: http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0#Function_body ________________________________ Inventive Designers' Email Disclaimer: http://www.inventivedesigners.com/email-disclaimer
Received on Thursday, 22 November 2012 12:43:40 UTC