Guidelines for XML Query Test Suite Submissions

Licensing Issues and Acceptance

Conformance to Schemas and File Format

Test Structure

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

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

Feature Name


string literals (quoted strings)  
integer literals  
URI literals  
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() )  
element constructors including text-node content for those elements
Namespace declaration in prolog Including default
+, - with two operands  
fn:true(), fn:false()  
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:position, fn:last  
“is” predicate  
The Constructors: xs:string, xs:anyURI, xs:integer, xs:decimal, xs:float, xs:double, xs:boolean, xs:date, xs:dateTime, xs:time  

Collations and URI’s

Static Typing

Optional Features and vendor Specific Features

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>

Any error condition for which there is not a predefined code, the "*" symbol should be used.

External Variable Tests

External variable tests are designed to run queries, whose external variable values are defined by outsite agents. The main catalog will define an <input-query> element. The results of the input query (s) are bind to external variables defined in the main query. The <input-query> element require three attributes, namely:

  1. name - specifies the name of the input query (no extension required).
  2. variable - the name of the variable to which the results of the query should be binded.
  3. date - the date the query was written.

The following table illustrates a typical entry for an external variable test case:

  <test-case is-XPath2="false" name="extvardeclwithtype-17" ...>
   <description>External Variable used to evaluate a boolean expression ... .</description>
   <spec-citation spec="XQuery" section-number="4.14" ... />
   <query name="extvardeclwithtype-17" date="2006-02-09"/>
   <input-file role="principal-data" variable="input-context">emptydoc</input-file>
   <input-query variable="x" name="extvardeclwithtypetobind-17" date="2006-02-09"/>
   <output-file role="principal" compare="Text">extvardeclwithtype-17.txt</output-file>

The following are the input query and the main query that corresponds to the entry above:

Input Query

   (: Name: extvardeclwithtypetobind-17 :)
   (: Description: Binding boolean expression for extvardeclwithtype-17.:)

   let $var := fn:true() or fn:true()
   return $var

Main Query

     (: Name: extvardeclwithtype-17 :)
     (: Description: Evaluates an external variable used in a boolean expression:)
     (: Both queries perform the operation. :)

     declare variable $x as xs:boolean external;
     $x or fn:false()

Note the name(s) of the external variable(s) defined in the main query must match the names of the variable(s) defined in the input queries ("x" in this case). The main query must be a stand alone query, it should have no input infosets.

Module Import Tests

Module Import tests are accepted as optional features of the XML Query Specifications as outlined in sections 4.2 and 5.2.5. The following example from the catalog file illustrates a typical entry for a module import test.

<test-case name="modules-simple" FilePath="Modules/ModuleImport/" scenario="standard" Creator="Jane Doe">
<description>Import simple library module</description>
<spec-citation spec="XQuery" section-number="4.11" section-title="Module Import" section-pointer="id-module-imports"/>
<spec-citation spec="XQuery" section-number="4.2" section-title="Module Declaration" section-pointer="id-module-declaration"/>
<query name="modules-simple" date="2005-12-05"/>
<module namespace="http://www.w3.org/TestModules/test1">test1-lib</module>
<input-file role="principal-data" variable="input-context">emptydoc</input-file>
<output-file role="principal" compare="XML">modules-simple.xml</output-file>

Note the presence of a required <module> element and the required namespace attribute. There must be one <module> element for every module that is imported by the main query. There also must be one <module> element for each library module that the imported module may in turn have. The content of the <module> element is an IDREF type that must match an ID attribute from a <module> element defined in the sections area of the catalog file as a child of the <sections> element. The following example illustrates the matching ID definition for the example above.

<module ID="test1-lib" FileName="TestSources/test1-lib" Creator="Jane Doe">
<description last-mod="2005-12-05">Simple library module</description>

Note that the file "TestSources/test1-lib" does not have an extension. The extension for this file is defined at "test-suite/@XQueryFileExtension".

The main query (and any imported library module with subsequent imports) must have an import statement with a prefix and a namespace URI. The namespace URI must match the namespace URI defined in the catalog file. The module import statements must be between the "(: insert-start :)" and the "(: insert-end :)" comments. Please refer to the "Guidelines for Running The XML Query Test Suite" for further usage of these comments. The following example shows the query that corresponds to the example above.

(: insert-start :)
import module namespace test1="http://www.w3.org/TestModules/test1"
declare variable $input-context external;
(: insert-end :)

And the corresponding relevant section from the library module.

module namespace test1="http://www.w3.org/TestModules/test1";

It is highly recommended (but not required) that any library module contain the "lib" string as part of its name.

XML and Namespaces

XML Encoding

Related Specifications

XPath Compatibility

Results and Serialization

Expected Results

Webmaster Last modified: $Date: 2006/06/12 00:47:57 $ by $Author: aeisenbe2 $

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.