This collection of test cases in the XQTS format does not exist for testing an XPath, XQuery or XSL-T implementation, but to verify the test harness tool that runs an actual XQTS test suite. Therefore, some tests intentionally fail in this test suite. XQuery 1.0: An XML Query Language http://www.w3.org/TR/2004/WD-xquery-20041029/ XQuery 1.0 and XPath 2.0 Functions and Operators http://www.w3.org/TR/2004/WD-xpath-functions-20041029/ XQuery 1.0 and XPath 2.0 Data Model http://www.w3.org/TR/2004/WD-xpath-datamodel-20041029/ XQuery 1.0 and XPath 2.0 Formal Semantics http://www.w3.org/TR/2004/WD-xquery-semantics-20040220/ XML Schema Part 2: Datatypes http://www.w3.org/TR/xmlschema-2/ XML Schema Errata Current practice is to have one Errata document for all parts of Schema. http://www.w3.org/2001/05/xmlschema-errata XML Query Use Cases http://www.w3c.org/TR/xquery-use-cases/ The XML InfoSets should be canonicalized and compared. A 'fragment' refers to an XML based instance which has multiple top-level elements and NO XML declaration. The comparator for this should simply wrap the entire fragment in a container element and perform XML comparisson. Each line of non-whitespace text should match. New-line sequences may vary and should be neutralized. Due to issues with the XML serialization of certain characters (e.g. '<'), it is not possible to simply compare the actual and expected results. Rather (as is the case with the 'Fragment' comparator) the test harness should convert the results into valid XML (by adding a container element) and perform comparisson on the XML canonicalized versions of the results. Only the presence/absence of this file is significant, not its content. Automated comparison is not possible. the output should be inspected by a human. This is the source that is handed in to the processor as the initial input sequence, setting the "evaluation context" as described in XQuery chapter 2. These are sources that may be read by functions such as fn:document() as the query is evaluated. These are schema definitions that may be referenced by sources or in the query. These are dtd definitions that may be referenced by sources or in the query. This is an output (either text or XML) that will contain the query results. If the processor invocation sequence accepts a filename for results, this name may be passed, possibly prefixed by a partial directory path to allow storage of the results in a separate directory tree. This is an output (text file tagged .log) that will contain the captured "console" output for a command-line invocation, or equivalent messages from a harness. The main goal is to capture error messages that came from the processor. A test lab may choose to capture console output for every test case, in which case the presence of this element is a signal that the console log of this test contains messages that are significant to the pass/fail determination. A query this is expected to produce valid results. Principal input should always be specified, even if the query doesn't have any PathExpr. A query this is expected to raise a parsing/syntax error at query parse time. Principal input should always be specified, even if the query doesn't have any PathExpr. A query this is expected to raise a runtime error at query parse time. Runtime errors in this case include those raised by static typing rules. Principal input should always be specified, even if the query doesn't have any PathExpr. XQuery Test Suite Catalog Bibliography example with extra comments and PIs. Contains just a "doc" element, no comments/text/PIs. Data about a filesystem represented in XML. Data about a filesystem represented in XML with namespace-qualified names. Small tree with element names in mixed namespaces. Use @index to identify elements precisely. Customer name/address file with some non-ASCII characters. Like TreeCompass, but with comments and PIs off the root. PI targets vary. All text nodes must have non-whitespace characters. A "compass" tree that has just one child, of an abnormal name, off the center node. One attribute each on west and center. A "compass" tree that has just a text node and no child element off the center node. A tree intended to allow many kinds of path expressions. Need multiple attributes on center, west, and south, plus @mark scattered around. Mix of text and element children in many places, but east should have only a text node. All text nodes must have non-whitespace characters. Top element is far-north. A "compass" tree that has just one "south" element at the top, bearing one "mark" attribute. A "compass" tree that has center elements off the real center node. Use @mark to distinguish center elements. "Real" center must have multiple element children, some with duplicate names (south-east). Repeating attribute names used, including same name on elements of the same name. Comments and text nodes are strewn about. All text nodes must have non-whitespace characters. A "compass" tree that has several "south" elements, some stacked within each other. Use "mark" attributes at several levels and on all south elements. A "compass" tree that has no content at all in center or west, no attributes anywhere. Data that fits first example in XQuery 3.11. Data that fits later examples in XQuery 3.11. Simple document with all node kinds Simple document with namespaces Source document for namespace copy modes Data for various NIST tests Data for various NIST tests (abbreviated, unabbreviated syntax) Data for fn:lang tests. Data for various NIST tests Source document for Function Declaration tests Data for the the XML Query XMP use cases Data for the the XML Query XMP use cases Data for the the XML Query XMP use cases Data for the the XML Query XMP use cases Data for the the XML Query TREE use cases Data for the the XML Query SEQ use cases Data for the the XML Query RDB use cases Data for the the XML Query RDB use cases Data for the the XML Query RDB use cases Data for the the XML Query STRING use cases Data for the the XML Query STRING use cases Data for the the XML Query NS use cases Data for the the XML Query PARTS use cases Data for the the XML Query SGML use cases A Schema validated xml file, that contains values for data types. Can be used by any test. A Schema validated xml file, that contains values for some of the order by tests generated by NIST. Data for id and idref related functions. A Schema validated XML file containing certain special types e.g. interleave types, union types, anySimpleType A schema validated XML file containing QName and QName derived types. A Scehma validated xml file with NOTATION elements Data for normalize-space functions Schema for XQTSCatalog A Schema for atomic.xml A Schema for orderData.xml A Schema containing certain special types e.g. interleave types, union types, anySimpleType A schema containing QName and QName derived types A Schema for NOTATION data A schema for simple context tests Library module for "modules-none" query Library module with empty namespace Simple library module Library module with namespace URI set to empty string. Simple library module Library module with colliding definitions Library module with colliding definitions Library module with circular includes Library module with circular includes Library module with interesting context Library module with definitions for various NIST tests. The version of Unicode that is used to construct expressions. The statically-known collations. The implicit timezone. The circumstances in which warnings are raised, and the ways in which warnings are handled. The method by which errors are reported to the external processing environment. Whether the implementation is based on the rules of [XML 1.0] and [XML Names] or the rules of [XML 1.1] and [XML Names 1.1]. One of these sets of rules must be applied consistently by all aspects of the implementation. Any components of the static context or dynamic context that are overwritten or augmented by the implementation. Which of the optional axes are supported by the implementation, if the Full-Axis Feature is not supported. The default handling of empty sequences returned by an ordering key (sortspec) in an order by clause (empty least or empty greatest). The names and semantics of any extension expressions (pragmas) recognized by the implementation. The names and semantics of any option declarations recognized by the implementation. Protocols (if any) by which parameters can be passed to an external function, and the result of the function can returned to the invoking query. The process by which the specific modules to be imported by a module import are identified, if the Module Feature is supported (includes processing of location hints, if any.) Any static typing extensions supported by the implementation, if the Static Typing Feature is supported. The means by which serialization is invoked, if the Serialization Feature is supported. The default values for the byte-order-mark, encoding, media-type, normalization-form, omit-xml-declaration, standalone, and version parameters, if the Serialization Feature is supported. Limits on ranges of values for various data types, as enumerated in 5.3 Data Model Conformance. The destination of the trace output is implementation-defined. See 4 The Trace Function. For xs:integer operations, implementations that support limited-precision integer operations must either raise an error [err:FOAR0002] or provide an implementation-defined mechanism that allows users to choose between raising an error and returning a result that is modulo the largest representable integer value. See 6.2 Operators on Numeric Values. For xs:decimal values the number of digits of precision returned by the numeric operators is implementation-defined. See 6.2 Operators on Numeric Values. See also 17.1.3.3 Casting to xs:decimal and 17.1.3.4 Casting to xs:integer. If the number of digits in the result exceeds the number of digits that the implementation supports, the result is truncated or rounded in an implementation-defined manner. See 6.2 Operators on Numeric Values. See also 17.1.3.3 Casting to xs:decimal and 17.1.3.4 Casting to xs:integer. It is implementation-defined which version of Unicode is supported by the features defined in this specification, but it is recommended that the most recent version of Unicode be used. See 7.1 String Types. For 7.4.6 fn:normalize-unicode, conforming implementations must support normalization form "NFC" and may support normalization forms "NFD", "NFKC", "NFKD", "FULLY-NORMALIZED". They may also support other normalization forms with implementation-defined semantics. The ability to decompose strings into collation units suitable for substring matching is an implementation-defined property of a collation. See 7.5 Functions Based on Substring Matching. All minimally conforming processors must support year values with a minimum of 4 digits (i.e., YYYY) and a minimum fractional second precision of 1 millisecond or three digits (i.e., s.sss). However, conforming processors may set larger implementation-defined limits on the maximum number of digits they support in these two situations. See 10.1.1 Limits and Precision. Various aspects of the processing provided by 15.5.4 fn:doc are implementation-defined. Implementations may provide external configuration options that allow any aspect of the processing to be controlled by the user. Support for additional user-defined or implementation-defined types is implementation-defined. (See 2.6.1 Representation of Types) Some typed values in the data model are undefined. Attempting to access an undefined property is always an error. Behavior in these cases is implementation-defined and the host language is responsible for determining the result. (See 5 Accessors) For any implementation-defined output method, it is implementation-defined whether sequence normalization process takes place. (See 2 Sequence Normalization) If the namespace URI is non-null for the method serialization parameter, then the parameter specifies an implementation-defined output method. (See 3 Serialization Parameters) If the value of the normalization-form form parameter is not NFC, NFD, NFKC, NFKD, fully-normalized, or none then the meaning of the value and it's effect is implementation-defined. (See 4 Phases of Serialization) The effect of additional serialization parameters on the output of the serializer, where the name of such a parameter must be namespace-qualified, is implementation-defined or implementation-dependent. The extent of this effect on the output must not override the provisions of this specification. (See 3 Serialization Parameters) The effect of providing an option that allows the encoding phase to be skipped, so that the result of serialization is a stream of Unicode characters, is implementation-defined. The serializer is not required to support such an option. (See 4 Phases of Serialization) An serializer may provide an implementation-defined mechanism to place CDATA sections in the result tree. (See 5.1.4 XML Output Method: the cdata-section-elements Parameter) These tests should fail -- it's intentional. The query is a syntax error, but the test-case requires a pass. emptydoc fail-1.txt The query is a dynamic error due to call to fn:error(), but the test-case requires a pass. emptydoc fail-2.txt The query evaluates to a xs:string, but the test-case requires a parse-error with error code XPST0003. emptydoc XPST0003 The query evaluates to a xs:string, but the test-case requires a runtime-error with error code FORG0006. emptydoc FORG0006 The query evaluates to a parse error with error code XPST0003, but the test case required a parse error with code XPST0081. emptydoc XPST0081 The query evaluates to a parse error with error code XPST0003, but the test case required a runtime error with code FORG0006. emptydoc FORG0006 The query evaluates to a dynamic error with error code FOER0000, but the test case required a parse error with code FOER0000. emptydoc FOER0000 The query evaluates to a dynamic error with error code FOER0000, but the test case required a parse error with code FORG0006. emptydoc FORG0006 The query evaluates to an xs:string, but none of the baselines match. emptydoc succeed-9-1.txt succeed-9-2.txt succeed-9-3.txt The query evaluates to an xs:string, but the baseline doesn't match. emptydoc succeed-10.txt The query contains a parse error, but none of the baselines match. emptydoc succeed-11-1.txt succeed-11-2.txt FOER0000 The query contains a runtime error due to call to fn:error(), but none of the baselines match. emptydoc succeed-12-1.txt succeed-12-2.txt FORG0006 The test-case requires a parse error with error code XPST0003, but the query file does not exist. emptydoc XPST0003 The query evaluates to a xs:string literal, but the specified baseline file does not exist. emptydoc fail-DOESNOTEXIST.txt An "Ignore" baseline with a query that generates a runtime error. emptydoc An "Ignore" baseline with a query that generates a parse error. emptydoc Space is significant. emptydoc fail-3.txt Test that XML documents that differs on the top level, are flagged(type being runtime-error). emptydoc fail-18.txt Test that XML documents that differs on the top level, are flagged(type being runtime-error, comparing as Fragment). emptydoc fail-18.txt Test that XML documents that differs on the top level, are flagged(type being standard, comparing as XML). emptydoc fail-18.txt Test that XML documents that differs on the top level, are flagged(type being standard, comparing as fragment). emptydoc fail-18.txt Top elements differing in name, should fail. emptydoc fail-22.txt Attributes differing with the XML prefix, should fail. emptydoc fail-23.txt Test that XML documents that differs on the top level, are flagged(type being runtime-error, comparing as Fragment). emptydoc fail-18.txt These tests should succeed. A 'success' test where the query, which is a string literal, evaluates to a string, which must match the baseline. emptydoc succeed-1.txt A 'success' test where multiple output baselines exists. emptydoc succeed-2-1.txt succeed-2-2.txt succeed-2-3.txt succeed-2-4.txt succeed-2-5.txt succeed-2-6.txt A 'parse-error' specifying error code XPST0003, and where the query also is that; a syntax error. emptydoc XPST0003 A 'runtime-error' specifying error code FOER0000, and where the query, containing a call to fn:error(), also results in that. emptydoc FOER0000 A 'runtime-error' specifying error code XPTY0004, and where the query, contains an invalid operator mapping. While the test case is specified as a runtime error, some implementations detects it at compile time, but should nevertheless flag it as a passed test case(even though it failed at compile time instead of runtime). emptydoc XPTY0004 The query results in a parse error with error code XPST0003, while the test-case contains many baselines, one of them the error code XPST0003. emptydoc succeed-6-1.txt succeed-6-2.txt XPTY0004 XPST0003 The query results in a runtime error with error code FOER0000, while the test-case contains many baselines, one of them the error code FOER0000. emptydoc succeed-7-1.txt succeed-7-2.txt XPTY0004 FOER0000 A 'standard' test with multiple baselines that caused an assert crash in KXQTS. emptydoc succeed-8.txt XQST0046 A test whose comparison method is 'Fragment'. Caused assert in KXQTS. bib2 succeed-9.txt A test which accepts any runtime error code, by specifying "*". emptydoc * A 'standard' test that accept output, a particular error code, plus any error code(yes, it makes no sense). emptydoc succeed-11.txt XQST0038 * An "Ignore" baseline with a query that generates output. emptydoc The scenario is runtime-error despite it not having an error baseline, and despite that we succeed on a non-error baseline. This could the driver not handle. succeed-13.txt Check that an XML prolog is not considered a processing instruction when comparing. succeed-14.txt