[Bug 29251] [xslt30] Conformance and optional features

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

--- Comment #6 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
> * takes one or more functions as arguments,
> * returns a function as its result.

Perhaps this is simpler? I agree to your (a), which means such processors
should implement maps and arrays, not function items.

An analogy to streaming comes to mind. I have the feeling that this feature
should mean that a "function item" cannot be invoked (absorption). But
inspecting whether something is a function item should be allowed, so that both
your option (a) and (b1/b2) can co-exist.

This can lead to dynamic errors only in the case of map/array-style invocation,
where the actual item turns out being a function and not a map.

This means that if a processor follows (a), it is possible to do "$f instance
of function(*)", it will simply return true for maps and arrays, and false
otherwise (it cannot be a function item).

Likewise, it should be possible to do function-name($f), where $f can be a map
or an array, in which case the name is the empty sequence. Another outcome is
not possible (unless a type error). And function-arity($f) will always return
1, or an error.

This is then consistent between your (a) and (b), where in the case of (b)
those functions SHOULD return something useful, if the function item comes from
an external input sequence.

Going this way, it will allow users to have <xsl:param name="m-or-a"
as="function(*)" />, which can then contain a map or an array. And
"function(xs:int) as xs:string" can be a map with int keys or an array.

I think this is not too hard to get right (might be even simpler than your
original proposal), and even though it marginally differs from XQuery, I think
it does so for good reasons (and perhaps XQ31 wants to bring its definition in
line with this, if there's some interest).

I would prefer not to differentiate between b1 and b2, because it may be
inevitable when using a library package that such items at some point "exist".
Opting for the inspection, but not absorption rule makes this as painless as
possible. It's a bit like C# 4, which supports the async keyword for
asynchronous processing. C# 3 users can not use it, but can still call into
libraries build with C# 4+ that use the async keyword.

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

Received on Monday, 2 November 2015 17:12:00 UTC