Test Suite for XQuery 1.0. See http://www.w3.org/XML/Query/test-suite/. XQuery 1.0: An XML Query Language http://www.w3.org/TR/xquery/ XQuery 1.0 and XPath 2.0 Functions and Operators http://www.w3.org/TR/xpath-functions/ XQuery 1.0 and XPath 2.0 Data Model http://www.w3.org/TR/xpath-datamodel/ XQuery 1.0 and XPath 2.0 Formal Semantics http://www.w3.org/TR/xquery-semantics/ 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/ XML Syntax for XQuery 1.0 (XQueryX) http://www.w3.org/TR/xqueryx/ XSLT 2.0 and XQuery 1.0 Serialization http://www.w3.org/TR/xslt-xquery-serialization/ 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 comparison. 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 comparison 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. A query this is expected to produce valid results. Principal input should always be specified, even if the query doesn't have any PathExpr. The initial query returns an <xqx:xquery> element (Trivial Embedding of XQuery). This embedded query is then executed to produce the final result. 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 fn-data-1 test. 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 DTD validated xml file, that contains data for the ID/IDREF function tests. A non 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 (schema-based). More data for id and idref related functions (schema-based). 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 Source file generated XML Benchmark Project's xmlgen utility. See http://www.xml-benchmark.org/. The declarations of a C++ file described in XML. A description of an graphical user interface. A file containing different forms of whitespace. A file containing ' ]' as a text node. Corner case unicode codepoints. Corner case unicode codepoints, second case. An element name containing 0xBC. Contains the codepoint 188 in an NCName. A namespace declared with a namespace declaration, as well as in the internal subset. An XML file which has two xml:id attributes with the same value. An XML file which has an invalid xml:id attribute. An XML file which has xml:id attributes. An XML which is in ISO-8859-1 encoding. Document containing namespace-sensitive constructs. Document to test erratum DM.E05. Document containing elements with various restricted and extended types. Document containing an element with mixed content but statically could have element only content. 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 the id/idref functions tests A schema for simple context tests A schema for examples.xml. A schema user defined types and constructor tests A schema defining a list of unions. Test schema for Errata XQ.E6. Test schema that contains an attribute declaration. Test schema that contains two complex types, one of them with a mixed content. Schema for complex types with simple content Schema illustrating various namespace-sensitive constructs. Schema to test erratum DM.E05. Schema to test erratum XQ.E18. Schema containing extended and restricted types. Schema with unique/id/idref constraints. A simple collection of documents. bib reviews A simple collection of documents. bib reviews books Library module for "modules-18" query Library module for "modules-18" query 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. Library module with invalid namespace prefix ("xml") Library module with variable on different namespace than target. Module that imports a schema and uses types from it. Module that imports a schema and uses types from it. Module that imports a schema and uses types from it. Module that imports a schema and uses types from it. Module that imports a schema and uses types from it. Module that imports a schema and uses types from it. Module that imports another module and uses a variable from it, testing circular dependencies. Module that imports another module and uses a function from it, testing circular dependencies. Module that imports another module and uses a variable from it, testing circular dependencies. Module that imports another module and uses a function from it, testing circular dependencies. Module that imports another module and uses a variable from it, testing circular dependencies pass case. Module that imports another module and uses a function from it, testing circular dependencies pass case. Module with simple and schema-element() types, used for functions'parameters and return results. Module with schema-attribute() types, used for functions' parameters and return results. Module with cyclic recursive imports. Module with cyclic recursive imports. Module that contains both private and public function declarations (XQuery 1.1). 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. The result of an unsuccessful call to an external function (for example, if the function implementation cannot be found or does not return a value of the declared type). 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. The result of casting a string to xs:decimal, when the resulting value is not too large or too small but nevertheless has too many decimal digits to be accurately represented, is implementation-defined. See 17.1.1 Casting from xs:string and xs:untypedAtomic. 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. The manner in which implementations provide options to weaken the stable characteristic of 15.5.6 fn:collection and 15.5.4 fn:doc are implementation-defined. 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) Test string and numeric literals in XQuery. Contains tests verifying the function calling mechanism; not a particular function implementation. Tests in this group focus on the axes named in XQuery 3.2.1.1 and the / and // step operators of 3.2.1. Abbreviated versions (@ vs. attribute::) are included. NodeTests are typically *, node(), or a name. Tests in this group take the axes as a given and focus on the NodeTest syntax in XQuery 3.2.1.2. Includes explicit names, *, and the various kind tests that look like functions. Tests in this group take the axes as a given and focus on the NodeTest syntax in XQuery 3.2.1.2. Includes explicit names, *, and the various kind tests that look like functions. Tests in this group take the axes as a given and focus on the NodeTest syntax in XQuery 3.2.1.2. Includes explicit names, *, and the various kind tests that look like functions. Tests that construct sequences Tests that construct sequences using the comma operator Tests that construct sequences using the RangeExpr Simple tests to evaluate filter sequence expressions. Tests for combining Sequences The general comparison operator"=" The general comparison operator"!=" The general comparison operator "less than (<)" The general comparison operator "less than or equal (<=)" The general comparison operator "greater than (>)" The general comparison operator "greater than or equal (>=)" Tests in this group focus on the FLWOR expressions in XQuery 3.8. Tests for the FOR part of the FLWOR expression syntax Tests for the FOR part of the FLWOR expression syntax Tests for the FOR part of the FLWOR expression syntax Tests for the 'at' variable in FLWOR expression. Tests for the LET part of the FLWOR expression syntax Tests for the LET part of the FLWOR expression syntax Tests for the LET part of the FLWOR expression syntax Tests for the WHERE part of the FLWOR expression syntax Tests for the ORDER BY part of the FLWOR expression syntax Tests for the ORDER BY part of the FLWOR expression syntax Tests for the ORDER BY part of the FLWOR expression syntax Tests for the RETURN part of the FLWOR expression syntax Tests involving "Ordered" and/or "unordered" Tests in this group focus on the conditional expressions in XQuery 3.10. Tests for the XQuery comment syntax Implementations are allowed to define an implicit context for their queries. What this means is that an XQuery expression can use the '.' or '/' axes without specifying any explicit context to bind these to. The binding of the implicit context to some input document is an implementation specific detail and should be handled by the individual test harness. New function in XQuery 1.1 Returns an xs:QName with the namespace URI given in the first argument and the local name and prefix in the second argument. Function Returns an xs:NCName representing the local-name part of the single xs:QName argument Function Returns an xs:NCName representing the namespace-URI part of of the single xs:QName argument Tests for the FOR part of the FLWOR expression syntax Tests on path expressions using the schema import feature Tests dealing with the static typing of axes step expressions Tests dealing with the static typing of functions Tests for expressions involving static type failures in FLWOR expressions Tests for fn:element-with-id function (introduced by erratum; implementation is optional for XQuery 1.0) example queries that illustrate requirements gathered from the database and document communities. An XML query language should have the ability to extract elements from documents while preserving their original hierarchy. This Use Case illustrates this requirement by means of a flexible document type named Book. Although sequence is not significant in most traditional database systems or object systems, it can be quite significant in structured documents. This use case presents a series of queries based on a medical report. One important use of an XML query language will be to access data stored in relational databases. This use case describes one possible way in which this access might be accomplished. The example document and queries in this Use Case were first created for a 1992 conference on Standard Generalized Markup Language (SGML). This use case is based on company profiles and a set of news documents which contain data for PR, mergers and acquisitions, etc. Given a company, the use case illustrates several different queries for searching text in news documents and different ways of providing query results by matching the information from the company profile and the content of the news items. This use case is based on a scenario in which a neutral mediator is acting with public auction servers on behalf of clients. The reason for a client to use this imaginary service may be anonymity, better insurance, or the possibility to cover more than one market at a time. This use case is based on a "parts explosion" database that contains information about how parts are used in other parts. This test suite group contains XMark, the XML Benchmark Project which was kindly donated to W3C's XQuery Test Suite. Frans Englich is marked as the creator of these tests and this is for the purpose of being able to locate the maintainer. The original author of these tests is the XML Benchmark team, see http://www.xml-benchmark.org/. This test suite group contains FunctX, a collection of XQuery functions. They were written by Priscilla Walmsley, but is maintained by Frans Englich within the XQTS. Test cases for extended QName syntax introduced in XQuery 1.1 Test cases for higher order functions in XQuery 1.1 Test cases for head() and tail() functions in XQuery 1.1 Test cases for switch expression introduced in XQuery 1.1