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 3312 - XPST0080, XPST0003 and XPST0051 overlaps
Summary: XPST0080, XPST0003 and XPST0051 overlaps
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XPath 2.0 (show other bugs)
Version: Candidate Recommendation
Hardware: Other Linux
: P2 normal
Target Milestone: ---
Assignee: Don Chamberlin
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-05 14:33 UTC by Frans Englich
Modified: 2006-10-16 11:59 UTC (History)
0 users

See Also:


Attachments

Description Frans Englich 2006-06-05 14:33:18 UTC
XPST0080 reads as follows:

'The target type must be an atomic type that is in the in-scope schema types and is not xs:NOTATION or xdt:anyAtomicType, optionally followed by the occurrence indicator "?" to denote that an empty sequence is permitted [err:XPST0080]'

XPST0051:

"If a QName that is used as an AtomicType is not defined as an atomic type in the in-scope schema types, a static error is raised [err:XPST0051]."

XPST0051 and XPST0080 overlaps when a non-atomic type is referred to in a cast/castable as expression. Examples:

$input cast as xs:anyType
or
$input cast as xs:doesNotExist

That XPST0080 also discusses the absence(or presence) of '?', making it overlap with XPST0003. I don't think it has to mention '?' because the grammar clearly specifies it, as for all other expressions. I think it would reduce potential overlaps by not discussing '?' in the definition of XPST0080.

I suggest to reduce the scope of XPST0080. Proposed wording:

In the first paragraph, replace:

"The target type must be an atomic type that is in the in-scope schema types and is not xs:NOTATION or xs:anyAtomicType, optionally followed by the occurrence indicator "?" to denote that an empty sequence is permitted [err:XPST0080]."

with:

"The target type must be an atomic type that is in the in-scope schema types[XPST0051]. In addition, the target type cannot be xs:NOTATION or xs:anyAtomicType[XPST0080]. The optional occurrence indicator "?" denotes that an empty sequence is permitted."


Frans
Comment 1 Don Chamberlin 2006-06-13 16:57:59 UTC
Frans,
On June 13, 2006, the Query and XSLT working groups considered your comment and decided to accept the changes you propose. These changes will be reflected in the next version of the XPath and XQuery specifications. Thank you for your suggestions on improving our error messages.
Regards,
Don Chamberlin (for the Query and XSLT working groups)
Comment 2 Frans Englich 2006-08-04 10:46:07 UTC
I don't think sufficient changes has been done, so I reopen.

Apart from that invalid casting combinations are discussed in 3.12.3 Cast and 3.12.4 Castable, it is also mentioned in 17.1 Casting from primitive types to primitive types:

<quote>
[XML Schema Part 2: Datatypes Second Edition] defines xs:NOTATION as an abstract type. Thus, casting to xs:NOTATION from any other type including xs:NOTATION is not permitted. However, casting from one subtype of xs:NOTATION to another subtype of xs:NOTATION is permitted.

Casting is not supported to or from xs:anySimpleType. Thus, there is no row or column for this type in the table below. For any node that has not been validated or has been validated as xs:anySimpleType, the typed value of the node is an atomic value of type xs:untypedAtomic. There are no atomic values with the type annotation xs:anySimpleType at runtime.

Similarly, casting is not supported to or from xs:anyAtomicType. There are no atomic values with the type annotation xs:anyAtomicType at runtime, although this can be a statically inferred type.

An attempt to cast to any of the above three type raises a static error [err:XPST0080]XP
</quote>

That is, as I see it F&O specifies a behavior that contradicts what was implemented in this report.

I guess the actual problem is that the XQuery and F&O specs duplicate each other. I think the proper solution is to fix that. However, the easiest and least intrusive way, is probably to remove the last paragraph, "An attempt to cast to any of the above three type raises a static error", and add [errorcode] markups inline in accordance with how 3.12.3 Cast and 3.12.4 Castable was edited.

This was brought to my attention by Ying Lu in private mail.

Also, I don't think the changes proposed in the original comment is implemented in the internally publicized drafts, but I presume that's expected.


Frans
Comment 3 Frans Englich 2006-10-16 11:59:47 UTC
There was no comment when Ashok resolved[1] this report but I'll simply assume this is fixed.


1.
http://lists.w3.org/Archives/Public/public-qt-comments/2006Sep/0314.html