W3C

Guidelines for XML Query Test Suite Submissions

Licensing Issues and Acceptance

Tests submissions must use the Grant II: Grant of License for Contributed test Cases Published Outside a W3C Recommendation. This license grant, for non-participant test case Contributors, is described Policies for Contribution of Test Cases to W3C.
The XML Query Working Group and XSL Working Group will, at their sole discretion, determine what tests are incorporated in the test suite.

Conformance to Schemas and File Format

Submissions must be valid with respect to "XQTSCatalog.xsd" schema file.
All submissions must be in a ZIP, tar or gzip file formats.
Please add your test cases to the "XQTSCatalogSubmission.xml" document that we have provided.

Test Structure

Entries in the catalogue file should contain citations of document sections, using both the section number and section name, whenever possible. This practice is highly recommended. A typical test catalogue entry is illustrated below.

<test-case name="test001" FilePath="Axes" ... >
...
<query name="test001.xq" date="2003-02-25">
<description>Child Element Test</description>
</query>
<input-file role="principal-data" context="default" variable="input-context">TreeCompass</input-file>
<output-file role="principal" compare="XML">test001.xml</output-file>
</test-case>

Submitters should indicate any potential problems with the tests.
Negatives tests will be accepted. However, they must be identified as such in the catalog file. Please see the Error Tests Section below for futher information. A typical negative test is illustrated below:

(: Name: test001 :)
(: Test Description: count function with missing argument :)

fn:count()

Variable names, function names, etc., should not contain any copyrighted information or any company name or any other text identifying a company.
Submitted tests should be minimal in nature and independent of one another.
Submitted tests must at least include a “Name” comment and a “Description” comment. These comments must appear as the first two lines of the file.
Submitters should reuse existing input files whenever possible.
Tests involving dates, times and dateTime should use an explicit timezone (whether optional or required). Tests designed to evaluate implicit timezone should omit the timezone component.
Submitted tests for a particular section must include only functionality defined by that section and by the provided foundation features. The XML Query Working Group defines the following features as foundation features:

Feature Name	Comments
string literals (quoted strings)
integer literals
URI literals
Parentheses
empty-sequence constructor ()
concatenation (comma operator) for sequence
expression comments
/ and //	for path steps
/ alone	for root node
all axes	for both expanded and abbreviated forms
node tests (e.g., text() )
Predicates
element constructors	including text-node content for those elements
Namespace declaration in prolog	Including default
+, - with two operands
fn:true(), fn:false()
fn:not()
and, or
string equality with XPath 1.0 semantics
numeric equality and inequality
node compare (these operators == and != backing up ‘node-equal’)
accessor functions: fn:data, fn:node-kind
fn:empty
fn:count
fn:position, fn:last
fn:string-length
fn:string-to-codepoints
“is” predicate
The types: xs:string, xs:anyURI, xs:integer, xs:decimal, xs:float, xs:double, xs:boolean, xs:date, xs:dateTime, xs:time

Collations and URI’s

When no collation is specified, the Unicode-Codepoint collation is assumed. Tests should be written with that in mind.
URI’s must be based on the www.example.com domain.

Static Typing

Submitted tests should obey the Static Typing rules, except for tests intended to evaluate violations of the Static Typing rules.
Submitted tests must not rely on any static typing extensions.

Optional Features and vendor Specific Features

Submitted tests that evaluate non-optional features should not use optional features.
Submitted tests should not include any vendor specific extensions (pragmas).

Error Tests

Error conditions that can be mapped to the conditions specified in the appendices of the XML Query specifications should include the error code stated for that condition. The following example from the catalog file illustrates one of such conditions:

<test-case name="Literals036" FilePath="Expressions/PrimaryExpr/Literals/" scenario="parse-error" Creator="John Doe">
<description>Test for invalid decimal literal</description>
<spec-citation spec="XQuery" section-number="3.1.1" section-title="Literals" section-pointer="id-literals"/>
<query name="Literals036.xq" date="2005-02-03"/>
<input-file role="principal-data" variable="input-context">emptydoc</input-file>
<expected-error>XPST0003</expected-error>
</test-case>

XML and Namespaces

Submitted tests should be independent of XML versions “1.0” and “1.1” and XML Namespaces versions “1.0” and “1.1” features unless the purpose is to evaluate those features.

XML Encoding

Submitted tests should use UTF-8 encoding.

Related Specifications

Submitted tests should be based exclusively on the XQuery specifications and the Functions and Operators specifications. Some tests may rely on the Formal Semantics, Data Model and Serialization documents, however those specifications are not being directly tested.

XPath Compatibility

The test-group element in the catalog may have the optional attribute is-XPath2="no". If this attribute is not present, when it is assumed that all descendent test cases may or may not be XPath 2.0 tests.
The test-case element in the catalog may have the optional attribute is-XPath2="yes|no". If this attribute is not present, then it is assumed that this test case may or may not be an XPath 2.0 test. If any test-group ancester of this element has is-XPath2="no", then this test-case element cannot have is-XPath2="yes". Over time, all test-case elements will have this attribute defined.

Results and Serialization

Tests in the XQTTF test suite rely on the serialized form of the test result in order to check correctness. Thus, any feature whose effect is not captured as part of the serialized result of a query, should be explicitly checked as part of the test query itself. For example, typing information is not present in the serialized results of an XQuery expression.

Expected Results

Submitters must provide expected results for all submitted tests.
When serializing content of a typed element where the type is atomic, any lexical representation of the value may be serialized. To minimize the number of expected results per test case, the input value used to construct the typed element should be identical to the result if this input value was cast to xs:string. If this is true, then only one expected result with the serialized value in its original lexical form is required for this test case. However, if the intent of the testcase is to test other lexical representations, then two expected results must be created where one result would contain the value if it was cast to xs:string, and the other in its original lexical form

Webmaster · Last modified: $Date: 2005/08/10 17:31:59 $ by $Author: liam $

Copyright © 1994-2005 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.