[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
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




------- Comment #5 from jmdyck@ibiblio.org  2007-08-07 02:16 -------
(In reply to comment #4)
> 
> The FS has been reluctant to introduce normalization rules that take
> account of the value, as distinct from the type, of the operands:

As far as the processing model is concerned, values aren't available
statically, so can't be a basis for normalization. (Even just taking account of
the type can be problematic, causing circularities if we're not careful.)

> I suppose that the fix that makes most sense is one that infers a
> cardinality of zero-or-one for any predicate value that is a numeric
> literal, without doing the incorrect normalization to subsequence().

If we don't normalize such cases to a special form, then I think it would be
fairly difficult for the FS to infer a restricted cardinality, and perhaps
impossible to do so without requiring implementations to infer a restricted
cardinality in other unintended cases.

So, I believe the feasible solutions are:

1) Change 'NumericLiteral' to 'IntegerLiteral' in 4.2.1 / Norm / rule 1+3 and
4.3.2 / Norm / rule 1. (Simple, but changes the inferred static type when the
predicate is a DecimalLiteral or DoubleLiteral.)

2) Change fn:subsequence to (say) fs:sub, which would be defined to have the
same static semantics as fn:subsequence, but without the rounding in its
dynamic semantics. This could either be done just in those three normalization
rules (which might be somewhat confusing), or throughout the FS.