- 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