
Guidelines for XML Query Update Test Suite Submissions
Licensing Issues and Acceptance
Conformance to Schemas and File Format
- Submissions must be valid with respect to "XQUTSCatalog.xsd" schema file.
- All submissions must be in a ZIP, tar or gzip file formats.
- Please add your test cases to the "XQUTSCatalogSubmission.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="id-insert-expr-06" FilePath= ... >
<description>Evaluates a simple insert expression with "after" clause only. ... </description>
<spec-citation spec="XQUPDATE" section-number="2.4.1" ... section-pointer="#id-insert"/>
<state time="0">
<query name="id-insert-expr-06" date="2007-06-04"/>
<input-file role="principal-data" variable="input-context">works-mod</input-file>
</state>
<state time="1">
<query name="id-insert-expr-06-test" date="2007-06-04"/>
<input-file role="principal-data" variable="input-context">works-mod</input-file>
<output-file role="principal" compare="Fragment">id-insert-expr-06.xml</output-file>
</state>
</test-case>
|
- Tests for which the <input-file> element in the catalog file references the "emptydoc" file are not required
to make any variable mapping back to the <input-file> element. In other words the following declaration is not
required to be present in the test case:
(: insert-start :)
declare variable $input-context external;
(: insert-end :)
|
- 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: id-insert-expr-023 :)
(: Description: Evaluation of simple insert expression where source expression is an updating expression. :)
(: insert-start :)
declare variable $input-context external;
(: insert-end :)
let $var := $input-context/employees[1]/employee[2]
return
do insert (do insert <salary>150000</salary> into $var) into $var
|
- Variable names, function names, etc., should not contain any
copyrighted information or any company name or any other text
identifying a company. However test submitters are allowed to use a company name as
the value of the "featureOwner" attribute of the <test-group> element.
- 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.
- Submitted tests should be insensitive to boundary-space, that is, in direct
element constructors there should be no boundary space between open/close tags and enclosed
expression.
- Tests involving the decimal and integer data types should use no more than 18 digits.
- Test involving the data types xs:date, xs:time, xs:dateTime, xs:gYear, xs:gYearMonth,
the maximum value of the year component should be no more than 4 digits, and the maximum number of
fractional second digits must be no more than 3.
- For tests involving the int, long, short and byte data types, please see the Schema specifications for limits
on those data types.
- Submitted tests for a particular section must include only
functionality defined by that section and by the provided
foundation features.
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 Update 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="id-insert-expr-029" FilePath="InsertExpressions/" scenario="runtime-error" Creator="Carmelo Montanez">
<description>Evaluates an insert expression where the target expression evaluates to a number.</description>
<spec-citation spec="XQUPDATE" section-number="2.4.1" section-title="Insert" section-pointer="#id-insert"/>
<state time="0">
<query name="id-insert-expr-029" date="2007-06-04"/>
<input-file role="principal-data" variable="input-context">employeesNIST</input-file>
<expected-error>XUTY0005</expected-error>
</state>
</test-case>
|
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:
- name - specifies the name of the input query (no extension required).
- variable - the name of the variable to which the results of the query should be binded.
- date - the date the query was written.
The following table illustrates a possible entry for an external variable test case:
<test-case name="extvardeclwithtype-17" ...>
<description>External Variable used to evaluate a boolean expression ... .</description>
<spec-citation spec="XQuery" section-number="4.14" ... />
<state time = "0">
<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>
</state>
</test-case>
|
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. At this point, it is not forseen that a lot of tests will be available for the
Update facility test suite.
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 Update
specifications and the Main XQuery specifications. Some tests may rely
on the Formal Semantics, Data Model, Functions and Operators and Serialization documents,
however those specifications are not being directly tested.
Results and Serialization
- Tests in the XQTTF Update 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.
- Many tests involve operations on floats/doubles and coverting those results to
strings. Even as one explicit value is given, the task force realizes that
other values may also be acceptable. In such cases submitters are encouraged
to sumbit values that may differ. The task force will eventually determine
if such values are within the acceptable range.
Webmaster · Last modified:
$Date: 2007/10/04 15:56:22 $ 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.