[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.

Received on Tuesday, 7 August 2007 02:16:40 UTC