[Bug 29251] [xslt30] Conformance and optional features

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

--- Comment #3 from Michael Kay <mike@saxonica.com> ---
>1) If possible, I would prefer to enumerate the exact function list. I understand they are visible, but in many likewise situations we enumerate for completeness.

I've given a few examples but I would prefer to avoid a normative list: it
invites inconsistencies. We changed between XQ30 and XQ31 to using the function
properties explicitly to avoid this problem.


2) I thought the term "function item" was changed to "function"?

Yes. I sometimes feel the need to use "function item" to distinguish a function
as the value of an item from a function declaration e.g. a stylesheet function.

3) I would prefer the system-property to be called
"xsl:supports-higher-order-functions". It matches the text better, plus it
covers better what it does. 

No, it's actually a misnomer. If the HOF feature isn't supported then you can't
do

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.



And a few caveats that we may or may not need to address:

4) 
> The effect of this rule is that in such an implementation, it is impossible 
> to construct function items other than maps and arrays.


>Perhaps unlikely, but not entirely inconceivable, the initial match selection and global context item *may* contain function items. These are not constructed *in* the implementation, but can be provided from external sources. We should probably say what happens then.

Yes, I have addressed this. I've commoned up the language used for
non-schema-aware processors to say that several optional features, if absent,
constrain the data model by disallowing certain kinds of item, and generalizing
the existing XTDE1665 error code to cover all these constraints in the same
way.

5) 
>I don't think we should forbid using (compiled) packages that can operate on function items. In fact, I don't think we can, because a package can be compiled with another version of a processor and it may not be visible to the package. I think it is too high a constraint to impose on package builders if they want to market their packages.

The way I've written the rules, (a) a processor that doesn't support the HOF
feature rejects certain syntactic constructs, and (b) may throw a dynamic error
if it comes across (non-array/map) function items in incoming data. It's
permitted to pass such items through transparently if it wants.

6)
>On the same token: don't we have a rule of some sort on packages that are build with support for streaming or schema-awareness, used by a stylesheet build with lesser support?

We haven't spelled out all the implications.

7)
>As a result of (5) and (6), such packages *may* return function items. We should say what happens if you try to match them (predicate pattern dot-matches-all). Of course, you can't do anything useful with them, but you can encounter them.

It's covered by the general dynamic error condition. But I'll expand the notes
a little.

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

Received on Friday, 30 October 2015 12:05:04 UTC