[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





------- Comment #16 from jmdyck@ibiblio.org  2007-10-31 05:55 -------
(In reply to comment #14)
> One other concern with the proposed change is that removing the special case
> rules from subsequence causes static type errors to occur in XQTS queries such
> as K-RangeExpr-11 and K-ForExprPropositionalVar-23.

As far as I can tell, those tests should already be raising errors. More
precisely, an implementation that conforms to the Formal Semantics and does not
support a static typing extension will raise a type error during static type
analysis of either of those tests.

For instance, consider K-RangeExpr-11:
   subsequence(-3 to -1, 1, 1) eq -3

For inferring the static type of the call to fn:subsequence, you might think
that the first rule of 7.2.13 applies, yielding xs:integer. However, static
type analysis always takes place on the normalized query.  Normalization
transforms the query to:

   fs:eq(
      fs:convert-operand(
         fn:data((
            subsequence(
               fs:to(
                  (fs:unary-minus(fs:convert-operand(fn:data((3)),1.0E0))),
                  (fs:unary-minus(fs:convert-operand(fn:data((1)),1.0E0)))
               ),
               fs:convert-simple-operand(fn:data(1),1.0E0),
               fs:convert-simple-operand(fn:data(1),1.0E0),
            )
         )),
         "string"
      ),
      fs:convert-operand(
         fn:data((
            fs:unary-minus(fs:convert-operand(fn:data((3)),1.0E0))
         )),
         "string"
      )
   )

The normalized call to subsequence() matches none of the specialized forms in
7.2.13; only the final catch-all rule applies. The type of the first arg is
xs:integer*, so prime(Type) is xs:integer and quantifier(Type) is *. Thus, the
inferred type of the subsequence() call is xs:integer*. Ditto for the fn:data()
call and fs:convert-operand() call that contain it.

So when it comes to typing the fs:eq() call, the xs:integer* argument type
isn't accepted by the rules of C.2, and static type inference fails. (A type
error is raised.)

Of course, an implementation is free to support a static typing extension, in
which the subsequence() call might have a type of xs:integer? or xs:integer. In
such a case, static typing of fs:eq() would succeed (yielding xs:boolean? or
xs:boolean respectively).

Received on Wednesday, 31 October 2007 05:55:54 UTC