Re: XForms 2.0 Draft review: The function Element

Erik,

I understand your point. But to be honest, I'm no fan of xf:var
either. I don't see value in duplicating XSLT functionality in core
XForms. XForms itself is already bloated enough.

We have an XPath module, which in my understanding should encapsulate
all XPath-specific stuff. I know this not the case yet (XPath language
is scattered across the spec), but it should be the goal. So, if we
feel the need to add functionality to XForms solely to circumvent some
XPath shortcomings, it definitely has to go to that module.

For a tighter Javascript integration xf:var and xf:function would be
useless. Ideally, you could switch the expression language and the
data model to Javascript/JSON. If you need shortcuts, you would
declare your variables and functions in Javascript syntax and include
or link that code to the host document.

Regards,
Uli.

On Wed, Jan 30, 2013 at 8:16 PM, Erik Bruchez <erik@bruchez.org> wrote:
> 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é
>>
>>



-- 
Ulrich Nicolas Lissé

Received on Tuesday, 5 February 2013 15:17:59 UTC