Draft Errata for XQuery 3.1: An XML Query Language

13 October 2017

Latest version:

https://www.w3.org/XML/2017/qt-errata/xquery-31-errata.html

Editor:

Michael Kay, Saxonica http://www.saxonica.com/

Copyright © 2017 W3C^® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

This document addresses errors in the XQuery 3.1: An XML Query Language Recommendation published on 21 March 2017. It records all errors that, at the time of this document's publication, have solutions that have been approved by the XML Query Working Group. For updates see the latest version of that document.

The errata are numbered, and are listed in reverse chronological order of their date of origin. Each erratum is classified as Substantive, Editorial, or Markup. These categories are defined as follows:

• Substantive: a change to the specification that may require implementations to change and that may change the outcome of a stylesheet or query.

• Editorial: a clarification, correction of a textual error, or removal of an inconsistency, where the Working Group does not believe that the intent of the specification has changed. The erratum may affect implementations or user-written queries and stylesheets if the previous lack of clarity in the specification resulted in a misreading.

• Markup: correction of formatting; the effect is cosmetic only.

Each entry contains the following information:

• A description of the error.

• A reference to the Bugzilla entry recording the original problem report, subsequent discussion, and resolution by the Working Group.

• Key dates in the process of resolving the error.

• Where appropriate, one or more textual changes to be applied to the published Recommendation.

Colored boxes and shading are used to help distinguish new text from old, however these visual clues are not essential to an understanding of the change. The styling of old and new text is an approximation to its appearance in the published Recommendation, but is not normative. Hyperlinks are shown underlined in the erratum text, but the links are not live.

A number of indexes appear at the end of the document.

Status of this Document

This is a public draft. It is maintained in accordance with the W3C process on Errata Management. None of the errata reported in this document must be considered normative.

Table of Contents

  Errata

     XQ31.E4   Some examples in the section concerned with the unary lookup operator are actually examples of postfix lookup.

     XQ31.E3   The definition of "pure union types" is unnecessarily complex.

     XQ31.E2   The term "Query Environment" (used in the definition of external functions) is not explained; furthermore it is used in XPath as well as XQuery.

     XQ31.E1   The introductory section on Atomizations mentions that FOTY0012 can be raised, but other errors (for example, FOTY0013) are also possible.

  Indexes

    Index by affected section

    Index by Bugzilla entry

    Index by error

[Definition] A pure union type is an XML Schema union type that satisfies the following constraints: (1) {variety} is union, (2) the {facets} property is empty, (3) no type in the transitive membership of the union type has {variety} list, and (4) no type in the transitive membership of the union type is a type with {variety} union having a non-empty {facets} property.

[Definition] A pure union type is a simple type that satisfies the following constraints: (1) {variety} is union, (2) {facets} is empty, (3) each type in its transitive membership is a generalized atomic type.

[Definition] Named functions. This is a mapping from (expanded QName, arity) to function^DM31. It supplies a function for each signature in statically known function signatures and may supply other functions (see 2.2.5 Consistency Constraints). Named functions can include functions with implementation-dependent implementations; these functions do not have a static context or a dynamic context of their own. external functions. [Definition] External functions are functions that are implemented outside the query environment. For example, an implementation might provide a set of implementation-defined external functions in addition to the core function library described in [XQuery and XPath Functions and Operators 3.1] . [Definition] An implementation-defined function is an external function that is implementation-defined .

[Definition] Named functions. This is a mapping from (expanded QName, arity) to function^DM31. It supplies a function for each signature in statically known function signatures and may supply other functions (see 2.2.5 Consistency Constraints). Named functions can include external functions. [Definition] An external function is any function that is neither specified as part of the language specifications (typically, in [XQuery and XPath Functions and Operators 3.1] ), nor defined using the features of the XQuery language. For example, an implementation might provide a set of implementation-defined external functions in addition to the core function library described in [XQuery and XPath Functions and Operators 3.1] . [Definition] An implementation-defined function is an external function that is implementation-defined .

The semantics of some XQuery 3.1 operators depend on a process called atomization. Atomization is applied to a value when the value is used in a context in which a sequence of atomic values is required. The result of atomization is either a sequence of atomic values or a type error [err:FO31TY0012]^FO31. [Definition] Atomization of a sequence is defined as the result of invoking the fn:data function, as defined in Section 2.4 fn:data ^FO31. fn:data function on the sequence, as defined in [XQuery and XPath Functions and Operators 3.1] .

The semantics of some XQuery 3.1 operators depend on a process called atomization. Atomization is applied to a value when the value is used in a context in which a sequence of atomic values is required. The result of atomization is either a sequence of atomic values or a type error. [Definition] Atomization of a sequence is defined as the result of invoking the fn:data function, as defined in Section 2.4 fn:data ^FO31.