[Bug 4841] [FS] Use of fn:subsequence in relation to normalization rules for filter expressions in FS

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4841


jmdyck@ibiblio.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|mike@saxonica.com           |jmdyck@ibiblio.org




------- Comment #3 from jmdyck@ibiblio.org  2007-07-10 22:38 -------
(In reply to comment #0)
> 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

I think you meant to say that it's an example of a *filter* expression, since
that's the subject of section 4.3.2. But in fact, it isn't a filter expression.
Of course, the whole expression is a PathExpr, but we're presumably only
interested in the a[3.4] step. That step is not a FilterExpr, but rather an
AxisStep (because the 'a' is not a PrimaryExpr but rather a ForwardStep
[specifically, a NameTest]). So the appropriate section of the FS is not 4.3.2,
but 4.2.1.

However, 4.2.1 has similar normalization rules to 4.3.2, so your point (that
//a[3.4] is normalized without involving the []_Predicates rule) is still
valid. (In fact, from the combination of 4.2.1 and 4.3.2, we can say that
[]_Predicates will never be applied to a NumericLiteral or a call to fn:last.)

So, I agree that the example of //a[3.4] is inappropriate for 4.2.2. Instead,
something like
    let $v := 3.4 return //a[$v]
(whose normalization *does* involve []_Predicates) would be appropriate for
4.2.2.

----

The XQuery spec defines the dynamic semantics of
    //a[3.4]
and
    let $v := 3.4 return //a[$v]
as follows.

Section 3.2.2 says: "If the value of the predicate expression is a singleton
atomic value of a numeric type or derived from a numeric type, the predicate
truth value is 'true' if the value of the predicate expression is equal (by the
'eq' operator) to the context position, and is 'false' otherwise."

Then section 3.5.1 says that if you compare 3.4 (a literal of type xs:decimal)
to the context position (of type xs:integer) via the 'eq' operator, the two
operands are converted (via subtype substitution) to their least common type
(i.e., xs:decimal) and then passed to op:numeric-equal(), which will always
return false.

Thus, a predicate expression of 3.4 will always result in a predicate truth
value of 'false', which will discard all items in the context sequence. So the
two example expressions above will always yield the empty sequence (assuming
they don't raise some error not pertinent to this discussion).

----

However, as you point out, the FS's normalizations for NumericLiteral as
predicate-expresion involve fn:subsequence, which involves rounding, which
allows //a[3.4] to return something other than the empty sequence. (Not "the
third item in //a", that's (//a)[3.4], but rather every element that is the
third a-child of some node in the context tree.) Thus, those normalizations
(specifically, 4.2.1 / Norm / rule 1+3 and 4.3.2 / Norm / rule 1) do not
correctly reflect the dynamic semantics defined in the XQuery spec.

Michael Kay's suggestion to change NumericLiteral to IntegerLiteral (extended
to all three normalization rules) would eliminate this problem, however it
would cause the FS to specify less precise types for cases involving other
NumericLiterals. This would affect conformance of implementations as follows:
-- Any currently-conforming implementation would become a conforming
implementation with a static typing extension for those cases.
-- Conceivably, certain currently-nonconforming implementations would become
conforming.

I'm not sure how it would affect conformance of queries; I'm not even sure
conformance of queries is defined.

Received on Tuesday, 10 July 2007 22:38:33 UTC