This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
version_declaration-001.xq is marked as <expected-error>*</expected-error>. Since I cannot see anything else wrong with the query, I'm assuming this si because there is a comment before the version declaratiion. This implies that an XQuery implementation is rquired to reject a version declaration that follows a comment. But the Specification [4.1] says: "If such a Comment [before the end of the version declaration] is present, the result is implementation-dependent." That to me seems to say that an implementation is *not* requiredto reject this query. I guess I'm asking for guidance here. Does what does <expected-error>*</expected-error> mean in this context? The same applies to version_declaration-002, version_declaration-003, version_declaration-004, and version_declaration-005.
Are you really sure about this? To me test version_declaration-001 has a text base line of "1 2"(same applies to the other tests). Therefore, the tests seems ok to me. So, I'm currently thinking about closing this report as invalid. <expected-error>*</expected-error> means that any error code is ok.
(In reply to comment #1) > Are you really sure about this? No - that's why I'm asking. > To me test version_declaration-001 has a text > base line of "1 2"(same applies to the other tests). What is "text base line" and where is it defined? > <expected-error>*</expected-error> means that any error code is ok. But does it also mean that "no* error code is ok? If so, that should be clarified in "Guidelines for Test Submission.html".
Here's the XQTSCatalog.xml entry for version_declaration-001 in CVS(I believe the catalog in the 1.0 release is identical): <test-case is-XPath2="false" name="version_declaration-001" FilePath="Expressions/PrologExpr/VersionProlog/" scenario="standard" Creator="Pulkita Tyagi"> <description>Demonstrates version declaration,the version.</description> <spec-citation spec="XQuery" section-number="4.1" section-title="Version Declaration" section-pointer="id-version-declaration"/> <query name="version_declaration-001" date="2005-10-05"/> <input-file role="principal-data" variable="input-context">emptydoc</input-file> <output-file role="principal" compare="Text">version_declaration-001.txt</output-file> <expected-error>*</expected-error> </test-case> Notice this line: <output-file role="principal" compare="Text">version_declaration-001.txt</output-file> This means there is a base line(something to compare the test result against) in file version_declaration-001.txt which should be compared with the Text method. Guidelines for Running the XML Query Test Suite says: 'Text: Same comparison as "XML fragment".' Low level details of the XML format is documented in XQTSCatalog.xsd(although I agree it can be more extensive). See the global type QueryErrorCode. So no, '*' does not mean no error code is acceptable, but that one error code that is any error code is acceptable. Thanks for asking, I hope it helps.
(In reply to comment #3) > So no, '*' does not mean no error code is acceptable, but that one error code > that is any error code is acceptable. My point still remains: the XQuery Specification does not seem to require an error in this situation. I would expect "Implementation dependent" to mean no diagnostic is required. If my reading is current, then the testsuite should not require an error code here.
Here's how I see it: That particular baseline, the one which allows any error code, doesn't allow no error code. However, since there also is a text baseline, an implementation can pass the test by evaluating to a result that matches the text baseline. Multiple baselines means that an implementation can pass the test in anyway that a baseline allows.
I believe that Frans' statements have all been accurate. We expect an implementation to pass if it returns "1 2" or it returns any error. This is, admittedly, a bit more restrictive than rules of the XQuery specification, which says: "If a version declaration is present, no Comment may occur before the end of the version declaration. If such a Comment is present, the result is implementation-dependent." If an implementation returns "2 3" and wants to challenge this, then we would have to accept it.
>If an implementation returns "2 3" and wants to challenge this, then we would have to accept it. And of course, if the comment has confused the implementation into decoding the query incorrectly, such a result is theoretically possible; so I think the spec should stay as it is.
Ok, I didn't realise that a test-case could have both output-file and expected-error as possible outcomes. I now understand that a test-case have zero or more output-file non-error outcomes *and* zero or more expected-error outcomes, any of which might be valid. That wasn't clear to me before. Thanks for the responses. I've marked the report as "invalid".