This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 3675 - fn:error(..) as an argument to another function/operator
Summary: fn:error(..) as an argument to another function/operator
Status: CLOSED INVALID
Alias: None
Product: XML Query Test Suite
Classification: Unclassified
Component: XML Query Test Suite (show other bugs)
Version: 1.0
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Frans Englich
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-08 10:25 UTC by Tim Mills
Modified: 2010-03-16 15:50 UTC (History)
0 users

See Also:


Attachments

Description Tim Mills 2006-09-08 10:25:22 UTC
Tests such as K-SeqZeroOrOneFunc-7:

zero-or-one(error()) 

are expected to return FOER0000 (unidentified error).

However, this is not an unidenfied error - it is a type checking error, since zero-or-one does not accept type "none".  As such, the test should accept XPTY0004  (static type checking error).
Comment 1 David Carlisle 2006-09-08 10:43:08 UTC
Surely though in this case if change is needed it would be a spec clarifcation
(that a function typed as none can be used anywhere) otherwise you would never be able to raise an error message to the user with  error() on a system doing the static type checks. It's not possible to declare a function that excepts a type of none, so by the reasoning here there is nowhere that error() can be used which would not generate a static type error, so the runtime error specified in the arguments to error() could never be generated.

I read the note in F&O

 Note that "none" is a special type defined in [XQuery 1.0 and XPath 2.0 Formal   Semantics] and is not available to the user. It indicates that the function never returns and ensures that it has the correct static type.


as meaning that any particular call to error() has whatever static type is needed at that point, so never raises a static type error.

David (Not a Working Group member)

Comment 2 Michael Kay 2006-09-08 11:57:34 UTC
I don't normally follow static typing discussions, because I decided long ago that the facility wasn't a good idea from a usability perspective. But surely, using error() should never cause a static type error. The whole point of error() is that it enables applications to detect errors dynamically, and if the simple existence of a call on error() can cause a static failure, then something is badly broken.

I guess this example is very artificial, a more realistic example would be

zero-or-one(if ($x=0) then error() else (1 div $x))

How does static typing handle that one?

Michael Kay
Comment 3 Frans Englich 2006-09-08 12:36:02 UTC
I believe that one would work, because:

"The type none matches no values. none is the identity for choice, that is (Type | none) = Type."(2.4.3 Content models)

So, I think the static type of the operand is the static type of (1 div $x).

Therefore, I think this would not yield a type error:

zero-or-one((error(), 1))

I can't deny nor confirm that zero-or-one(error()) is a type error, but if it is, it could be because there is no rule that lets 'none' match an arbitrary type, perhaps.. Though, I also think it would make sense that it is not a type error.

But I am neither a static typing guy; I've mailed Jérôme to see if he can have a look at this report.


Frans
Comment 4 Jerome Simeon 2006-09-18 23:54:08 UTC
Apologies for the late response.

The type 'none' is a subtype of every type. See subtyping Section 8.3.2-- t1 is a subtype of t2 iff every value v, v matches t1 implies v matches t2. Since no value matches 'none', none <: t for every t.

So the function zero-or-one(error()) type checks which I believe is the behavior that people would expect.

- Jerome
Comment 5 Tim Mills 2006-09-19 06:07:09 UTC
Thanks.  Might it be worth spelling that out for clarity in the notes of section 8.3.2?
Comment 6 Frans Englich 2006-09-19 11:00:15 UTC
Since how cases like zero-or-one(error()) is handled has now been clarified, what remains is the editorial suggestion by Tim(comment #5). Since this is not related to the tests, I've transfered the editorial change to #3716, and is closing this report as INVALID.

If this resolution is not satisfactory, feel free to re-open this report. If the resolution is ok, feel free to change status to CLOSED.