10696 2010-09-23 14:10:05 +0000 Tests that should allow XQST0022 2011-01-07 12:17:07 +0000 1 1 1 Unclassified XML Query Test Suite XML Query Test Suite 1.0.3 PC Windows NT RESOLVED FIXED P2 normal --- 1 mike benjie.nguyen benjie.nguyen public-qt-comments oldest_to_newest 39203 0 mike 2010-09-23 14:10:05 +0000 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. 39734 1 benjie.nguyen 2010-09-28 14:26:33 +0000 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. 39737 2 mike 2010-09-28 14:51:36 +0000 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? 41546 3 benjie.nguyen 2010-10-19 13:27:57 +0000 After thinking it over, I'm enclined to agree with Mike, and so I would also push for XQST0022 to be a legitimate answer. 43907 4 benjie.nguyen 2011-01-07 12:17:07 +0000 Hi Mike, I've updated the catalog to allow an alternate error code, and uploaded to CVS.