[Bug 11446] Provide alternate result for test K2-Literals-1

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

--- Comment #11 from Michael Kay <mike@saxonica.com> 2011-01-10 11:18:01 UTC ---
In response to comment #10, the specification states

If more than one error is present, or if an error condition comes within the
scope of more than one error defined in this specification, then any non-empty
subset of these errors may be reported.

Suppose the user wrote the query

return(a, b, c) + "

Intuitively, we might say there are two errors here: use of an
unknown/undeclared function "return", and there is an unclosed string literal.
A processor is allowed to report any subset of these two errors. Another
processor might decide that the real error is the use of a FLWOR expression
with no for or let clause; a third processor might decide that the user
intended to write "return (a, b, c) + " and that their error was to omit the
opening quotation mark. So the decision as to "what errors are present" amounts
to deciding how the query as written differs from some legal query that is
sufficiently similar, and processors may differ as to how they do this.

So the total set of errors present in the query is itself a processor
judgement, and the specification explicitly allows the processor then to report
only a subset of these errors.

Some people might read the specification of the processing model in 2.2.3.1 as
if it requires "parsing" to complete before variable and function names are
resolved, meaning that XPST0003 takes precedence over any other error. That's
not my reading, for a number of reasons:

(a) The text doesn't say the steps are sequential. It says "The query is
parsed. Variable and function names are bound." It doesn't say that one step
completes before the other starts. 

(b) it's perfectly normal for names to be bound during parsing where possible,
and if the WG had intended to disallow this, it would have said so.

(c) a literal reading of the processing model leads to all kind of absurdities,
for example it says "Before a query can be processed, its input data must be
represented as an XDM instance."

(d) the statement that any subset of static errors can be reported explicitly
contradicts any assertion that some static errors take precedence over others.

I think one can defend any static error message that has the property "if the
user fixed this, and also made some other unspecified changes, then the query
would be correct". And that means one can defend any static error message
whatsoever.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 10 January 2011 11:18:04 UTC