[Bug 29251] [xslt30] Conformance and optional features

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

--- Comment #5 from Michael Kay <mike@saxonica.com> ---
Wikipedia:

In mathematics and computer science, a higher-order function (...) is a
function that does at least one of the following:

* takes one or more functions as arguments,
* returns a function as its result.

(Although there does seem to be some disagreement about this definition).

We're restricting all use of functions (other than maps and arrays) as values,
not only the use of functions as arguments or results of (higher-order)
functions.

(In what follows, I'll use "FI" to mean an item whose value is a function other
than a map or array.)

I think there are two questions here: terminology (what do we call the feature?
what do we call the system property?), and substance (how exactly does a system
behave if it doesn't support this optional feature?).

On the issue of substance, I think it's important to align with XQuery. The
question of what is statically disallowed is fairly easy, the tricky bits come
with what is dynamically disallowed. On this side I think we can recognize two
classes of implementation in which the optional feature is not supported:

(a) implementations that don't define any representation of an FI. So the
dynamic problem never arises, for example they don't have to look at a value
returned from an extension function and say "check that the result isn't an
FI", because it can't be.

(b) processors that don't support the feature, but that work with an
implementation of the data model that provides a representation of FIs.
(Perhaps the product can exchange data model instances with another product
that does support the optional feature). There are two possible approaches
here, and I think we should allow both: (i) reject any FI in any value supplied
as "input to the processor" immediately with a dynamic error. (ii) allow FIs to
exist in input values, and raise an error only if some unsupported operation is
attempted, e.g. a dynamic function call, or an instance-of test: I don't think
we need to prescribe exactly which operations are allowed and which aren't
(we've banned the most interesting operations statically), only that the
product is entitled to raise a dynamic error at any stage if it encounters an
FI.

Note that this situation is very similar to the situation for a
non-schema-aware processor handling typed nodes, which is why I have tried to
common-up the rules.

On the terminology question, I agree that what I've proposed appears a little
inconsistent. "Higher order function feature" is what XQuery calls it and it's
a term that the user community will recognize, but it's not an accurate
technical description of the set of capabilities we are making optional. I was
looking for greater accuracy when selecting a language keyword.

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

Received on Monday, 2 November 2015 13:06:45 UTC