[Bug 29586] [XQ31] 2.5.6.2 The judgement subtype-itemtype(Ai, Bi)

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

--- Comment #12 from Jonathan Robie <jonathan.robie@gmail.com> ---
(In reply to John Snelson from comment #6)
> (In reply to Tim Mills from comment #3)
> > This appears to prevent a processor from using static type analysis to avoid
> > unnecessary function coercion.  For example, I think this requires that
> > 
> > function() { 1 } instance of function() as xs:integer
> > 
> > returns false.
> 
> I agree that your expression above should return false. I think it would be
> reasonable to allow an implementation to determine a stricter return type
> for the inline function using static typing if it can.

I'm not convinced that the specification allows this. Here's what it says about
the type of an inline function expression:

<quote>
[Definition: An inline function expression creates an anonymous function
defined directly in the inline function expression.] An inline function
expression specifies the names and SequenceTypes of the parameters to the
function, the SequenceType of the result, and the body of the function.
[Definition: An anonymous function is a function created by an inline function
expression.]

If a function parameter is declared using a name but no type, its default type
is item()*. If the result type is omitted from an inline function expression,
its default result type is item()*.
</quote>

For other functions, it's all about the statically known function signatures:

<quote>
[Definition: Statically known function signatures. This is a mapping from
(expanded QName, arity) to function signatureDM31. ] The entries in this
mapping define the set of functions that are available to be called from a
static function call, or referenced from a named function reference. Each such
function is uniquely identified by its expanded QName and arity (number of
parameters). Given a statically known function's expanded QName and arity, this
component supplies the function's signatureDM31, which specifies various static
properties of the function, including types and annotations.
</quote>

So for these functions, if you know the QName and arity, you know the return
type.


> Of course, your own static typing implementation could easily carry two
> types for the inline function expression - the "official" static type, and a
> static type for the way it behaves in practice. That would allow you to
> avoid the function coercion you were worried about.

Yes, and so far, I think that should be documented as a known incompatibility.

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

Received on Tuesday, 10 May 2016 18:13:36 UTC