[Bug 10696] Tests that should allow XQST0022

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

--- Comment #2 from Michael Kay <mike@saxonica.com> 2010-09-28 14:51:36 UTC ---
I think the examples were written when the rules were different, so whatever
they were trying to achieve at the time is historic.

I don't want to get into arguments about what's the correct error code,
especially for static errors where I don't believe there is ever a single 
"correct" answer - the error code/message is essentially a guess at what the
user intended to write, and such guesses will often be wrong. However, if an
error code can be produced by a reasonable parser then we should allow it, and
the following logic is entirely rational:

* I'm processing an attribute value

* I've seen an undoubled opening brace

* That means I've got to start parsing an enclosed expression

* Hang on, this is a namespace, enclosed expressions aren't allowed.

The kind of error you get here is also going to depend on how you handle nested
quotes. If you try to parse namespaces the way you parse attributes, then when
you see

xxxx="abc{" def "}ghi"

you're going to see an enclosed expression {" def "}. But if you parse
namespaces differently from attributes, you're going to see xxx="abc{", which
has an unmatched opening brace.

I'm sure you're not trying to suggest that XQST0022 should only be raised if
the enclosed expression within a namespace is otherwise error-free. Or are you?

-- 
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 Tuesday, 28 September 2010 14:51:38 UTC