- From: <bugzilla@wiggum.w3.org>
- Date: Mon, 09 Jul 2007 14:02:12 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4841 Summary: [F&O] [FS] Definition of fn:subsequence in relation to normalization rules for filter expressions in FS Product: XPath / XQuery / XSLT Version: Recommendation Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Functions and Operators AssignedTo: mike@saxonica.com ReportedBy: oliver@cbcl.co.uk QAContact: public-qt-comments@w3.org Under "Normalization" in section 4.2.2 of the FS specification, there is the following example: For example, the expression //a[3.4] always returns the empty sequence. This is really an example of a predicate expression, and so probably should be moved down to section 4.3.2 However, in section 4.3.2, the normalization rules say that filter expressions with numeric literal predicates normalize as follows: [PrimaryExpr PredicateList [ NumericLiteral ]]Expr == let $fs:sequence := [PrimaryExpr PredicateList]Expr return fn:subsequence($fs:sequence, NumericLiteral,1) and so the example above normalizes to: let $fs:sequence := //a return fn:subsequence($fs:sequence, 3.4, 1) According to the definition of fn:subsequence in Functions and Operators 15.1.10, fn:subsequence(3.4, 1) is defined to be $fs:sequence[fn:round(3.4) le $p and $p lt fn:round(3.4) + fn:round(1)] Apart from being a somewhat circular definition, this contradicts the example above, as it implies that //a[3.4] should return the third item in //a.
Received on Monday, 9 July 2007 14:02:18 UTC