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 2292 - Editorial: why is fn:number in section "14 Functions and Operators on Nodes"
Summary: Editorial: why is fn:number in section "14 Functions and Operators on Nodes"
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 1.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Linux
: P2 minor
Target Milestone: ---
Assignee: Ashok Malhotra
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2005-09-24 17:46 UTC by Frans Englich
Modified: 2006-09-18 10:38 UTC (History)
0 users

See Also:


Description Frans Englich 2005-09-24 17:47:02 UTC
I don't know whether issues like these are too minor to spend the time on it(if
so, tell me), but:

Why is fn:number put in section 14 Functions and Operators on Nodes? All other
functions and operators in section 14 are from what I can tell clearly bound to
nodes by that they have nodes as argument(s) or return values. fn:number, on the
contrary, takes either the context item node or an atomic value(may be a node
via atomization, of course).

Wouldn't "15.1 General Functions and Operators on Sequences" be a better place?
For example, the fn:boolean function is there, which can be said to be
conceptually similar(it derives a value from a sequence).

This is of course only a minor, editorial issue. Perhaps the current layout have
a clear motivation, which in that case would be interesting to hear.

Comment 1 Michael Kay 2005-09-24 17:50:26 UTC
Personal response: I think we discovered a while ago that the organisation of
functions into sections and subsections is impossibly arbitrary, and that trying
to rationalise it would be an unending task. Best just to accept it and let it be.

Michael Kay
Comment 2 Ashok Malhotra 2005-09-27 15:20:05 UTC
The original rationale for putting fn:number in section 14 was that if no
arguments are specified, the context item is used as the default argument.  As
Michael Kay says, we have not found an overarching organizing principle for
assigning functions to sections so the decisions are somewhat arbitrary.  I'm
going to close this bug.  If you feel strongly you can reopen it later.