2292 2005-09-24 17:46:33 +0000 Editorial: why is fn:number in section "14 Functions and Operators on Nodes" 2006-09-18 10:38:38 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Functions and Operators 1.0 Last Call drafts PC Linux CLOSED FIXED P2 minor --- 1 frans.englich ashok.malhotra public-qt-comments oldest_to_newest 6429 0 frans.englich 2005-09-24 17:47:02 +0000 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. Cheers, Frans 6430 1 mike 2005-09-24 17:50:26 +0000 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 6493 2 ashok.malhotra 2005-09-27 15:20:05 +0000 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.