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 13204 - [XP 3.0] XPTY0019 vs XPTY0020
Summary: [XP 3.0] XPTY0019 vs XPTY0020
Status: CLOSED WORKSFORME
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XPath 3.0 (show other bugs)
Version: Working drafts
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-11 10:16 UTC by Michael Kay
Modified: 2013-06-19 08:23 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2011-07-11 10:16:26 UTC
With the introduction of try/catch, predictability of error codes is becoming increasingly important. There seems to be a big overlap between XPTY0019 and XPTY0020.

Given the expression

23/x

when we look at the rules for the "/" operator, we raise XPTY0019 because the LHS is not a node; but when we look at the rules for the axis step "x", we raise XPTY0020 because the context item is not a node. There's no indication of which of these takes precedence. However, when the RHS of "/" is something other than an Axis Step, XPTY0019 is the only permitted error code; but when an Axis Step appears other than on the RHS of "/" (for example 23[x]), XPTY0020 is the only permitted code.

I'm finding it almost impossible to keep enough information through tree rewrites to maintain these distinctions: for example it means that "for $x in ABC where $x/@a return $x" cannot safely be rewritten as ABC[@a].

So I would like to propose that all uses of XPTY0019 be replaced by XPTY0020.
Comment 1 Michael Kay 2011-07-27 22:06:50 UTC
The WG decided to make no change to the specification.