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 30153 - Section on atomization mentions only error FOTY0012 can be raised, while immediately below specifying also FOTY0013
Summary: Section on atomization mentions only error FOTY0012 can be raised, while imme...
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XPath 3.1 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 trivial
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: 2017-07-26 19:23 UTC by Abel Braaksma
Modified: 2017-12-13 09:09 UTC (History)
3 users (show)

See Also:

Attachments

Description Abel Braaksma 2017-07-26 19:23:03 UTC 
I was trying to understand what xs:decimal(boolean#1) should throw (my Saxon version threw XPTY0117, which I think is incorrect).

The function conversion rules state that atomization is the first thing that takes place (if the argument to a function is expected to be of a generalized atomic type, which it is), and here I noticed that it (2.4.2 Atomization) says:

    The result of atomization is either a sequence of atomic values or a 
    type error [err:FOTY0012]

However, right below it, the third bullet says:

    * If the item is a functionDM31 (other than an array) or map a type 
      error [err:FOTY0013] is raised. 

I'm assuming the latter is correct, and the former sentence is either lacking an error, or should perhaps be more general, like "sequence of atomic values or a type error, see below".
Comment 1 Josh Spiegel 2017-07-26 19:34:05 UTC 
Yes, I think your assumption is correct.
Comment 2 Michael Kay 2017-07-26 22:12:16 UTC 
>my Saxon version threw XPTY0117, which I think is incorrect

I cannot reproduce that with any version from 9.5 onwards. I get FOTY0013, which is pretty clearly the intended result. Note that the normative rules for atomization are the rules of the fn:data function in F&O.
Comment 3 Abel Braaksma 2017-07-28 19:36:04 UTC 
> I cannot reproduce that with any version from 9.5 onwards.
The xsl:product-version I used for my test was: EE 9.7.0.15. Not the most recent, I know. I'd assume more recent versions show the correct error.
Comment 4 Jonathan Robie 2017-07-28 21:10:01 UTC 
(In reply to Josh Spiegel from comment #1)
> Yes, I think your assumption is correct.

I agree.
Comment 5 Andrew Coleman 2017-08-25 09:35:36 UTC 
Abel, do you want to see an editorial fix to be made as a result of this discussion, or are you happy to close this bug?
Comment 6 Abel Braaksma 2017-08-29 20:03:49 UTC 
(In reply to Andrew Coleman from comment #5)
> Abel, do you want to see an editorial fix to be made as a result of this
> discussion, or are you happy to close this bug?
Hi Andy, I am not sure I understand. If we are planning on an erratum some day, I would prefer to take this up to remove the ambiguity. If not, I can "live with it" :).

With other RECs I have even seen spelling errors corrected through errata, I don't know what our threshold is for (1) creating/publishing an erratum, or (2) inclusion in an erratum.

It's probably good to have an internal draft lying around somewhere, since such internal drafts are already publicly accessible, even if we never end up going through the publication process, at least there's a place people can look if they are confused or wondering whether a bug was already reported / dealt with.
Comment 7 Abel Braaksma 2017-08-29 20:11:55 UTC 
(In reply to Andrew Coleman from comment #5)
> Abel, do you want to see an editorial fix to be made as a result of this
> discussion, or are you happy to close this bug?
Sorry, I forgot my main question: "editorial fix", does that mean an in-place fix without need for republication, changing headers etc, etc? Like you sometimes see "This REC was updated in place on [date] to fix links"?
Comment 8 Abel Braaksma 2017-09-22 14:16:07 UTC 
To answer myself, from the latest summary of the WG meeting decisions, it will go into an errata document.
Comment 9 Andrew Coleman 2017-12-13 09:09:37 UTC 
This has been resolved in the errata document:
https://www.w3.org/XML/2017/qt-errata/xpath-31-errata.html#E1