[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 #15 from jmdyck@ibiblio.org  2007-10-31 02:28 -------
(In reply to comment #12)
> The changes proposed fail to provide a catch all case, and so the type is not
> defined for an argument with quantifier ? for example.

Whoops again! You're right, the four moved rules do not cover all cases.

> The typing rules could be made simpler (without changing the result) by just
> applying the following rules:
> 
> statEnv |-  QName of func expands to (FN-URI,"item-at")
> statEnv |-  Expr : Type  quantifier(Type) in { 1, + }
> --------------------------------------------------------
> statEnv |-  QName(Expr, 1) : prime(Type)
> 
> statEnv |-  QName of func expands to (FN-URI,"item-at")
> statEnv |-  Expr : Type
> --------------------------------------------------------
> statEnv |-  QName(Expr1, Expr2) : prime(Type) ?

An excellent simplification. (I had to do some quantifier-arithmetic to
convince myself that, in all cases, the resulting type was the same as
currently inferred, but I agree that it is.)

> Additionally, the static typing could be improved with the following rule:
> statEnv |-  QName of func expands to (FN-URI,"item-at")
> statEnv |-  Expr : Type  quantifier(Type) in { 1, + }
> --------------------------------------------------------
> statEnv |-  QName(Expr1, $last) : prime(Type)

In fact, fn:subsequence used to have such a rule, but it was removed in the
20050915 WD and hasn't returned. (See Bug 1728 Comment #7.) My impression is
that the removal was a mistake, and I think the rule should be reinstated (for
item-at). However, that won't be happening as part of this issue, and probably
not as an erratum either.