Re: Custom functions (Major re-write, please review)

Apparently I miss interpreted the XPath 3.0 spec. Michael Kay says "User-defined functions get no context item, position, or size. That's true both for named global functions and inline functions."

So I think our custom functions also shouldn't do that. Now that we have variables you can work around this limitation.

Example:

<var name="context" value="."/>
<var name="context-pos" value="position()"/>
<var name="context-size" value="last()"/>
<function signature="my:f() as number" value="$context-pos = $context-size"/>



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


[cid:image001.png@01CBF2F8.1DA19110][cid:image002.png@01CBF2F8.1DA19110][cid:image003.png@01CBF2F8.1DA19110]

On 13 Mar 2012, at 16:39, Nick Van den Bleeken wrote:

Erik,

I might interpret it incorrectly but reading the XPath 3.0 spec:

"The static context for the function body is inherited from the location of the inline function expression, with the exception of the static type of the context item which is initially undefined.

The variables in scope for the function body include all variables representing the function parameters, as well as all variables that are in scope for the inline function expression." [1]

I think the focus (context item, context position, and context size) is the same inside the function body and where the function is defined, you only don't have the static type information of the context item in the function body.

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<http://www.inventivedesigners.com>

1: http://www.w3.org/TR/xpath-30/#id-inline-func


On 12 Mar 2012, at 17:23, Erik Bruchez wrote:

Biased +1 ;)

In particular the function signature idea is in line with other suggestions to reduce markup, and the good part is that we don't have to reinvent the wheel for the syntax.

Where I have a doubt is whether we should define an initial context for the functions. Ideally there should be one defined, but unless I am mistaken XPath 3.0 still says there is no initial context, is that right? If so my main concern would be the ease of using an XPath 3.0 implementation out of the box to implement functions.

-Erik

On Thu, Mar 8, 2012 at 11:56 PM, Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com<mailto:Nick.Van.den.Bleeken@inventivegroup.com>> wrote:
Alex and I have had a good constructive discussion about custom functions on twitter. He summarized the discussion here https://gist.github.com/2002642

I think we should implement all remarks. What does the group think of this?

Kind regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 425 41 02<tel:%2B32%203%20425%2041%2002>
Office fax: +32 3 821 01 71<tel:%2B32%203%20821%2001%2071>
nick.van.den.bleeken@inventivegroup.com<mailto:nick.van.den.bleeken@inventivegroup.com>
www.inventivedesigners.com<http://www.inventivedesigners.com/>


<image001.png><image002.png><image003.png>

On 08 Mar 2012, at 18:22, Nick Van den Bleeken wrote:

All,

I've updated http://www.w3.org/MarkUp/Forms/wiki/Custom_XPath_functions I tried to make the text more XForms spec like (no longer XSLT spec like)

I made one change to what we agreed on the call yesterday.

The current spec doesn't allows you to intermix script and sequence child elements. I did this because you are allowed to use multiple sequence (and script) elements as the body of a function element to allow easy creation of result sequences. And if you allow multiple sequence (and script) elements it becomes a bit unclear what you want to achieve when you intermix those.

But I allow the author to override already defined functions. I also added an extra attribute override to let the author choose if he wants to override already defined functions. This has the nice consequence that a form author could use XForms implementation specific functions but include a declaration of those functions that will be used in implementations that don't have those functions (by setting override to no).

I put an example of how to fall back to an XPath implementation of a function if the processor doesn't support javascript in 'specification'.

If the form author writes the example like this it would even default to the native implementation if the XForms implementation has implemented the function:


<function name="my:foo" as="number" override="no">
   <param name="p" as="nodeset"/>

   <script type="text/javascript">
      foo(XForms.var.p);
   </script>
</function>

<function name="my:foo" as="number" override="no">
   <param name="p" as="nodeset"/>

   <sequence select="sum($p)"/>
</function>


As you can see in the example I name spaced all 'variables' this is best practice in javascript and many other languages.

===============================================================

I also needed to delete the following example because 'Within the body of a custom function, the focus is initially undefined; this means that any attempt to reference the context item, context position, or context size is a non-recoverable dynamic error.' I would like to follow XSLT's take on this, because this allows you to 'import' the function from anywhere without unexpected side effects.

Example: function selecting all elements called "name" in an instance.

<pre><nowiki>
<function name="my:get-names" as="nodeset">
    <sequence select="//name"/>
</function>
</nowiki></pre>


All comments are very welcome.

Kind regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 425 41 02<tel:%2B32%203%20425%2041%2002>
Office fax: +32 3 821 01 71<tel:%2B32%203%20821%2001%2071>
nick.van.den.bleeken@inventivegroup.com<mailto:nick.van.den.bleeken@inventivegroup.com>
www.inventivedesigners.com<http://www.inventivedesigners.com/>


<image001.png><image002.png><image003.png>


________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.


________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer


--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.


________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.


________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer