1754 2005-07-19 19:20:36 +0000 [FS] editorial: 7.2.1, 7.2.2, 7.2.10: normalizing calls to particular functions 2007-10-02 19:42:28 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Formal Semantics 1.0 Last Call drafts All All CLOSED FIXED consider for 1.1 P2 minor --- 1 jmdyck jmdyck public-qt-comments oldest_to_newest 4918 0 jmdyck 2005-07-19 19:20:36 +0000 7.2.1 The fn:last context function 7.2.2 The fn:position context function 7.2.10 The fn:min, fn:max, fn:avg, and fn:sum functions Norm [[ fn:last() ]]_Expr == ... [[ fn:position() ]]_Expr == ... [[ fn:sum() ]]_Expr == ... These normalization rules can't be applied in the normal way. If "fn" is bound to a different namespace, you don't want the rule to fire. On the other hand, if the function is invoked via a different prefix or via the default function namespace, you *do* want the rule to fire. So you have to do some static analysis on the expression before you can decide whether or not to apply the normalization. I suppose you could make that fit into the processing model, but it might be easier to treat it much like any other built-in function, and provide STA and DEv. 8960 1 simeon 2006-03-29 22:08:20 +0000 Fixed as suggested, relying on static and dynamic inference rules instead of normalization. - Jerome 12325 2 jmdyck 2006-10-05 23:08:24 +0000 In 7.2.1 and 7.2.2, the new STA rules look up fs:last and fs:position in statEnv.varType in order to get their type. But 3.1.2 tells us that "the type of $fs:position and $fs:last is always xs:integer", so it seems you could make the STA rules simpler: --------- statEnv |- (FN-URI,"last")() : xs:integer --------- statEnv |- (FN-URI,"position")() : xs:integer Moreover, this is exactly the conclusion one would draw by simply looking up fn:last or fn:position in statEnv.funcType. So given that section 7.2 is for functions "for which the standard normalization or static typing rules are not appropriate" and that "the static typing rules in this section always give more precise type information than the generic rule based on the function's signature", it would appear that fn:last and fn:position don't belong in 7.2. In the new DEv rules in 7.2.1 and 7.2.2, the conclusions dynEnv |- (FN-URI,"last")() => Value dynEnv |- (FN-URI,"position")() => Value use an undeclared form. Perhaps what you mean is dynEnv |- function (FN-URI,"last") with types on values yields Value dynEnv |- function (FN-URI,"position") with types on values yields Value 13603 3 simeon 2007-01-16 18:00:25 +0000 I am reluctant to make substantive changes to that section at this point. I merely fixed the dynamic rules as suggested to use the proper judgment. - Jerome 14100 4 jim.melton 2007-02-25 23:18:27 +0000 Closing bug because commenter has not objected to the resolution posted on 2007-01-16 15024 5 jmdyck 2007-05-06 08:59:50 +0000 In (7.2.1 and 7.2.2) / DEv / rule 1 / conclusion: dynEnv |- function (FN-URI,"last")() with types on values yields Value dynEnv |- function (FN-URI,"position")() with types on values yields Value the "()" shouldn't be there. 16995 6 jmdyck 2007-10-02 19:42:07 +0000 (In reply to comment #2) > it would appear that fn:last and fn:position don't belong in 7.2. It's possible that sections 7.2.1 and 7.2.2 could simply be dropped without loss, but there doesn't seem to be a significant problem with leaving them in. I'll consider it for the 1.1 document, and have made a note in the Status Whiteboard to that effect. (In reply to comment #5) > In (7.2.1 and 7.2.2) / DEv / rule 1 / conclusion: > dynEnv |- function (FN-URI,"last")() with types on values yields Value > dynEnv |- function (FN-URI,"position")() with types on values yields Value > the "()" shouldn't be there. The extraneous "()" have been removed via the fix for FS erratum E013. This fix has been committed to the source files for the next edition of the FS document. Consequently, I'm marking this issue resolved-FIXED, and CLOSED.