For what it's worth, I think this suggestion is worth the change.

If fn:boolean() was a "regular" function FORG0006 would be sensible, but it has a central role in type checking among the language specifications. For example, the 'where' clause defines itself with the fn:boolean function. FORG0006 would be issued even though fn:boolean() wasn't invoked, from the user's perspective.


Regards,
Frans

Taking into the resolution of #2559, and assuming Rys' suggestion in this report is accepted, the remaining usages of FORG0006 is in F&O, more specifically the functions fn:avg(), fn:max(), fn:min() and fn:sum(), as far as I can tell.

When FORG0006 is raised in those cases, it is as type errors. What distinguishes the functions are their special typing rules; conversions that are invoked, and that the sequence types of their arguments can't be expressed with conventional sequence type syntax.

If an argument to a function not listed above, does not match as per sequence type matching, XPTY0004 is raised(as per 3.1.5 Function Calls in XQuery, for example). What makes the functions above special is that their typing rules are not conventional, but it's still typing rules, especially from a user's perspective, as I see it.

Phrased differently, if changing fn:boolean() to issue XPTY0004 instead of FORG0006 due to "it would be more consistent with other type errors"(Rys), I think one could apply the same reasoning to making the same change to the above functions.

I think fn:boolean() is a more important and more central case than the aggregation functions, but perhaps at least worth consideration. One can as always balance the gain of the result against the other implications of changing the specifications at this stage, but perhaps it's not so big if fn:boolean() is to be changed anyway.


Regards,
Frans

My preference is to leave it alone. Trying to rationalise whether two different errors should share the same code is very difficult: I've made such proposals occasionally, for example based on reasoning that you should be able to do static rewrites without being constrained by the fact that the target construct differs from the source construct only in the error codes it raises. In this case I haven't seen any such rationale.

Avoiding overlap between error codes is another possible rationale. But XPTY0004 is a catch-all in the way it's defined; if we followed that principle then all type errors would be XPTY0004.

If there's a rationale to this proposal, it is that we should use a smaller number of coarser-grained error codes because that is likely to improve interoperability between products (two products producing the same code for the same condition). But if we adopted that route, we would have a single error code covering all errors. (Which might not be a bad thing, but it would undo a lot of work.)

I think we need to accept that there will be occasions - probably frequent occasions - when different implementations will raise different errors for the same condition. In most cases this is because there is more than one way of looking at the error: if the user writes preceeding::x, is that a malformed QName, an unknown axis, or an undeclared namespace prefix?

Commenting on #3:

I also think error codes is a tricky area; that implementors can have difficulty getting them right, and so forth. However, it was decided to normatively use error codes, so I wouldn't be so fast on accepting that implementors are fuzzy in this area(but that's of course only from my perspective of limited insight and experience).

If implementations have problems with error codes(or are suspected to have) I would say the suggestion in this report would improve interoperability. I don't see how consolidating error codes in this case would mean "we would have a single error code covering all errors". I agree it harmonizes in that direction, but I don't see how it means the specifications must go all the way.

I see a difference between error codes. For example, FORG0002 is constrained to the implementation of one single function. I have a hard time imagining how/why implementations would find it difficult to report that particular code, and therefore don't think there will be interoperability issues in that area.

However, when it comes to "type checking", it is a central piece which according to my experience stretches in and out through an whole implementation, and it often plays a large role in defining the implementation as a whole. For example, optimizations(AST rewrites), whether some JIT approach is in effect, etc etc, affects how "type checking" works in an implementation. Therefore, it wouldn't surprise me if error codes are fuzzy in that particular area.

Since error codes were chosen in the first place fine grained error codes are of interest(since that's the point; they more fine grained identify something), but if the end result is that implementors anyway will have difficulty with actually reporting them, it perhaps isn't of much use. Therefore it is perhaps sensible to not be too finegrained in those particular cases where it is deemed that implementations typically will have difficulty.

Further, Michael's last paragraph in #3 discusses that implementations may report different errors in queries that have multiple errors, and I think that's a problem of a slightly different kind. 

I can imagine there will no matter what be cases where error codes will diverge. I don't think "preceeding::x" is a very good example, a malformed QName and an unknown axis are syntax errors no matter what, and I think an implementation must work in a very strange way in order think "preceeding" is an undeclared namespace prefix. I think '"content" cast as xs:anyType*' is a more realistic example of where multiple error codes are possible; the syntactically valid cast expression contains XPST0051, while the end of the query contains a syntax error(XPST0003, the '*'). 


Regards,
Frans

On the 2006 April 18 telcon the joint WGs declined to take any action on this bug.
There were arguments on both sides.  The prevalent sentiment was that error behavior would in many, if not most, cases be implementation specific.  Also, error behavior would not be a criterion for interop compatibility.

> The prevalent sentiment was that error
> behavior would in many, if not most, cases be implementation specific.  Also,
> error behavior would not be a criterion for interop compatibility.

I was surprised by these two sentences in your response. I just reviewed the meeting minutes, in which we agreed (without objection) to close the issue without change. But there is nothing in the minutes to say that we believe that error behavior is, in most cases, implementation specific, and I am not sure how freely to interpret this comment. Our test suite *does* test for error conditions.

I think the part that is implementation-dependent involves the case where more than one error applies, in which case I believe the prevailing sentiment was that an implementation could choose which of these errors to raise. We decided that was not part of this issue, but a different issue which could be raised separately.