[Bug 3097] fn:Boolean should use error [err:XPTY0004].

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3097





------- Comment #4 from frans.englich@telia.com  2006-04-13 19:02 -------

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

Received on Thursday, 13 April 2006 19:02:58 UTC