- From: <bugzilla@jessica.w3.org>
- Date: Tue, 28 Sep 2010 14:51:37 +0000
- To: public-qt-comments@w3.org
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