[Bug 29251] [xslt30] Conformance and optional features

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29251

--- Comment #4 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
> let $f := math:pi#0 return $f()

> even though no higher order function is involved. We're disallowing all 
> expressions that return functions as their value, not simply functions that 
> accept or return functions.

For what it's worth, $f in your example is a function item, $f() a dynamic
function invocation. The term "higher order function" typically refers to
anything that involves creating, returning and invoking function items.
Besides, you called the section "27.X Higher-Order Functions Feature". It's a
bad mnemonic if the feature is called differently than the property.

Conversely, if we say "we don't support function items", it is not (entirely)
true. Every implementation must support them, you just can't use them, invoke
them, or return them.

I would dare say that for instance, one could define:

<xsl:template match=".[. instance of function(*)]">
    <xsl:message terminate="yes">We don't support function items</xsl:message>
</xsl:message>

And you can also do:

<xsl:template match=".[. instance of function(*)]">
    <xsl:try>
        <xsl:value-of select="'attempt (is it a map?): ' || map:keys(.)" />
        <xsl:catch>
            <xsl:message terminate="yes">
                We don't support function items
            </xsl:message>
        </xsl:catch>
    </xsl:try>
</xsl:message>

But perhaps this should fail. I mean in the sense that syntax ".[. instance of
function(*)]" is allowed, but ".()" is not. But ".('x')" can be a map.

Note, you wrote:

> The AnyFunctionTest sequence type is permitted and will match either a map 
> or array.

So that would violate the ideas laid out above. It feels kinda strange if we
have a sequence of function items (from external source) and it is treated as
if it is an empty sequence. But empty($f) on that sequence will return false,
while if($f instance of item()) will return true, and if($f instance of
function(*)) will return false.

That sounds somewhat similar to function(*) (but not map/array) being mapped to
xs:error.

I think I would prefer that we allow:
* operators castable as, cast as, instance of, is
* <, >, =, <=, >=, !=
* eq, ne, lt, gt, le, ge
* pattern .
* function-name, function-arity (or not)

And that we disallow
* dynamic function invocation
* partial function application
* inline functions
* arrow operator (?)
* core higher order functions

Note that, somewhat strangely, XP31 marked fn:load-query-module as higher order
and fn:transform not. Both are in the higher-order section, though neither
takes a function item as argument, or returns a function item.

The thing is, I think that this way it is *much* easier to implement. Instead
of special-case many situations, we can mark a set of functions, but default
operations remain to exist and default templates remain to be called.

We could even go one step further. Simply allow the whole syntax of XP31 (the
grammar) and say that any function item is wrapped in a new function with the
same arguments, with as body a call to fn:error(err:XTDExxxx).

This would prevent painstaking updates to the grammar parsing. It is the
"everything is allowed, except for a set of functions". This has the downside
for end-users to create a late surprise (they can create an inline function but
only receive an error when they call it).

In the end it is a little bit potáto - potàto what we choose, and my preference
would go to the least disruptive.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 2 November 2015 12:32:55 UTC