[Bug 4378] error in K2-NodeTest-21

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

Tim Mills <tim@cbcl.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tim@cbcl.co.uk

--- Comment #10 from Tim Mills <tim@cbcl.co.uk> ---
(In reply to Josh Spiegel from comment #9)

> The context item is unbound and has the static type item().  An
> implementation should be able to tell that the static type of the function
> body is empty.

In XQ30 4.18 Function Declaration, we read

[Definition: User defined functions are functions that contain a function body,
which provides the implementation of the function as an XQuery expression.] The
static context for a function body includes all functions, variables, and
namespaces that are declared or imported anywhere in the Prolog, including the
function being declared. Its in-scope variables component also includes the
parameters of the function being declared. However, its context item static
type component is absent[DM30].

So in the scope of the function body, the context item static type is absent,
not item().  

One might argue that XPTY0004 would be permissible as a static error, since if
the context item static type component is absent how can one successfully type
check the expression?

Perhaps it would have been better to say the the context item static type would
be "none" (from XQ10 Formal Semantics), or "xs:error" (which behaves in an
identical way to "none").

If you treat the context item as type none/xs:error, then the type of

 document-node(element(local:ncname))

is none?/xs:error? which is the same as empty-sequence().  On that basis,
XPST0005 should be permissible.

I'm of the opinion that whenever the compiler comes across something of the
form

if (condition)
then fn:error()
else ()

it's probably unwise to treat this as empty-sequence() without issuing a
warning to the user.  That said, the specification regarding xs:error states:

"xs:error? and xs:error* are identical to empty-sequence()."

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

Received on Monday, 28 September 2015 11:09:07 UTC