- From: <bugzilla@wiggum.w3.org>
- Date: Mon, 10 Apr 2006 21:34:45 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3097 ------- Comment #3 from mike@saxonica.com 2006-04-10 21:34 ------- 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?
Received on Monday, 10 April 2006 21:35:53 UTC