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 30321 - [XSLT30] (editorial) Section in fn:document explaining atomization of nodes assumes a single node can be atomized to a sequence of more-than-one, this is confusing
Summary: [XSLT30] (editorial) Section in fn:document explaining atomization of nodes a...
Status: RESOLVED WORKSFORME
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 minor
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-01 14:38 UTC by Abel Braaksma
Modified: 2018-12-02 20:47 UTC (History)
0 users

See Also:

Attachments

Description Abel Braaksma 2018-12-01 14:38:22 UTC 
The section in fn:document (20.1), the second bullet point, reads:

"For an item in $uri-sequence that is a node, the node is atomized. The result must be a sequence whose items are all instances of xs:string, xs:anyURI, or xs:untypedAtomic. Each of these values ...."

The text starts with "an item ... that is a node". If a node is atomized, it will typically lead to a sequence of one. If the typed value is a list type, it may return a sequence of more-than-one, but this requires a schema-aware processor.

I find this confusing. While the text is not technically wrong, I propose that in an upcoming erratum we clarify this, for instance by mentioning the exceptional case that can lead to more-than-one.
Comment 1 Michael Kay 2018-12-01 17:40:19 UTC 
I think that the spec should define what happens in the general case, and should not concern itself with the fact that for many users, the general case doesn't arise very often.
Comment 2 Abel Braaksma 2018-12-02 20:47:32 UTC 
Yes, you're right. Let's close this one, the list of bugs is already long enough and this appears to be not really a bug ;).