This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The following tests: K2-DirectConElemNamespace-44 K2-DirectConElemNamespace-61 K2-DirectConElemNamespace-63 K2-DirectConElemNamespace-67 K2-DirectConElemNamespace-69 All contain an unpaired "{" within a namespace declaration on a direct element constructor. The parser is entitled to assume that this signals the start of an EnclosedExpr within the namespace value, and therefore to report error XQST0022.
To be honnest I'm not sure about the exact goal of the test, since it reads "Use an inproperly enclosed expression inside an namespace declaration". The spec says : If the DirAttributeValue contains an EnclosedExpr, a static error is raised [err:XQST0022] Looking at example K2-DirectConElemNamespace-44.xq : /www.example.com/{ my feeling is that this expression is not valid per the grammar and therefore is err:XQST0003. The DirAttributeValue does not contain an EnclosedExpr since it is defined by EnclosedExpr ::= "{" Expr "}", and such a pattern cannot be found. I believe the parser should also be looking for {{ so I'm not sure why it would decide off the bat that { is an EnclosedExpr. One could also argue that { is only part of the unwise URI characters, so could be part of the uri (I'm not a URI expert, so maybe I'm wrong here). Maybe the example(s) should be changed though because I don't really understand what they try to acheive.
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?
After thinking it over, I'm enclined to agree with Mike, and so I would also push for XQST0022 to be a legitimate answer.
Hi Mike, I've updated the catalog to allow an alternate error code, and uploaded to CVS.