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

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> 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
> Office fax: +32 3 821 01 71
> nick.van.den.bleeken@inventivegroup.com
> www.inventivedesigners.com
>
>
>
>  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
> Office fax: +32 3 821 01 71
> nick.van.den.bleeken@inventivegroup.com
> 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
>