Errata for XQuery 1.0: An XML Query Language

31 March 2009

Latest version:
http://www.w3.org/XML/2007/qt-errata/xquery-errata.html
Editors:
Don Chamberlin, IBM Almaden Research Center http://www.almaden.ibm.com/
Jonathan Robie, Red Hat http://www.redhat.com

Abstract

This document addresses errors in the XQuery 1.0: An XML Query Language Recommendation published on 23 January 2007. 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:

Each entry contains the following information:

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.

Substantive corrections are proposed by the XML Query Working Group (part of the XML Activity), where there is consensus that they are appropriate; they are not to be considered normative until approved by a Call for Review of Proposed Corrections or a Call for Review of an Edited Recommendation.

Please report errors in this document using W3C's public Bugzilla system (instructions can be found at http://www.w3.org/XML/2005/04/qt-bugzilla). If access to that system is not feasible, you may send your comments to the W3C XSLT/XPath/XQuery public comments mailing list, public-qt-comments@w3.org. It will be very helpful if you include the string [XQerrata] in the subject line of your report, whether made in Bugzilla or in email. Each Bugzilla entry and email message should contain only one error report. Archives of the comments and responses are available at http://lists.w3.org/Archives/Public/public-qt-comments/.

Status of this Document

This is a public draft. None of the errata reported in this document have been approved by a Call for Review of Proposed Corrections or a Call for Review of an Edited Recommendation. As a consequence, they must not be considered to be normative.

The Working Group does not intend to progress these errata to normative status; instead, it intends to publish a second edition of the Recommendation incorporating these errata, and to progress the second edition to normative status.

Table of Contents

  Errata

     XQ.E30   Fixes an example by replacing the undefined variable <partno> {$p} </partno> with <partno> {$pn} </partno>).

     XQ.E29   State more explicitly that user-defined types in an imported schema add constructors for these types to the set of known function signatures.

     XQ.E28   A new non-normative appendix designed to give guidance on the handling of modules.

     XQ.E27   Specifies that leading and trailing whitespace are stripped from a PITarget specified in a SequenceType of form processing-instruction(PITarget) before it is tested to see if it is a syntactically valid NCName.

     XQ.E26   Corrects the description of precedence with respect to parentheses and square brackets.

     XQ.E25   Adds a missing word to an error description.

     XQ.E24   Clarifications on parsing leading / in XPath expressions.

     XQ.E23   Defines the meaning of "undefined" for Data Model properties.

     XQ.E22   Specifies conformance criteria for syntax extensions.

     XQ.E21   Allows (and encourages) the use of XML 1.0 editions newer than the Third Edition.

     XQ.E20   Corrects a list of examples of primitive atomic types.

     XQ.E19   Specifies rules that prevent the redefinition of certain predefined namespace prefixes.

     XQ.E18   Specifies that general comparisons cast an untyped operand to the primitive base type of the other operand rather than to the most specific type of the other operand.

     XQ.E17   Specifies that, in the order-by clause of a FLWOR expression, a user-specified collation applies only if the value of the ordering expression is of type xs:string or is convertible to xs:string.

     XQ.E16   Deletes unnecessary reference to RFC2396 from Normative References.

     XQ.E15   Removes references to error code FORG0001 from description of cast expression.

     XQ.E14   Calls attention to the entry in Appendix C that defines the initial values for context item, position, and size, which can be referenced in initializing expressions in variable declarations.

     XQ.E13   Disallows enclosed expressions inside a namespace declaration attribute, and clarifies handling of consecutive curly-braces, consecutive single-quotes, and consecutive double-quotes inside attribute values.

     XQ.E12   Specifies that an error results if the PITarget specified in a SequenceType of form processing-instruction(PITarget) is not a syntactically valid NCName.

     XQ.E11   Clarifies behavior of node constructors when base-URI in static context is undefined.

     XQ.E10   Clarifies that the default initial static type of the context item is undefined.

     XQ.E9   Specifies that, in a computed attribute constructor, if the QName of the constructed attribute has a namespace URI but no prefix, an implementation-dependent prefix is generated.

     XQ.E8   Deletes error code XQST0073, because it is redundant to error code XQST0093.

     XQ.E7   In Section 3.13 (Validate Expression), Rule 3c, deletes "Identity-constraint Satisfied" from the list of rules that are not applied during validation.

     XQ.E6   Tightens the rules for the in-scope schema definitions that must be present in an importing module.

     XQ.E5   Clarifies the conditions under which a castable expression may raise an error.

     XQ.E4   Adds more details to the rules defining permissible expression rewrites for optimization and other purposes.

     XQ.E3   For valid syntax, adds parentheses to the expansion for leading "/" and leading "//" in a path expression.

     XQ.E2   Reverses the order of Rules 1 and 2 in XQuery Section 3.7.3.1, Computed Element Constructors (processing of content sequence).

     XQ.E1   Specifies that error XQTY0086 applies to copied attribute nodes as well as copied element nodes, including copied attribute nodes that have no parent.

  Indexes

    Index by affected section

    Index by Bugzilla entry

    Index by construct

    Index by error-code


XQ.E30 - editorial

See Bug 6737

Description

Fixes an example by replacing the undefined variable <partno> {$p} </partno> with <partno> {$pn} </partno>).

History

29 Mar 2009: Proposed

29 Mar 2009: Accepted

Change

In I.2 Grouping (first code section):

Replace the text:

for $pn in fn:distinct-values(
      fn:doc("catalog.xml")/items/item/partno)
let $i := fn:doc("catalog.xml")/items/item[partno = $pn]
where fn:count($i) >= 3
order by $pn
return 
   <well-supplied-item>
      <partno> {$p} </partno>
      <avgprice> {fn:avg($i/price)} </avgprice>
   </well-supplied-item>

With:

for $pn in fn:distinct-values(
      fn:doc("catalog.xml")/items/item/partno)
let $i := fn:doc("catalog.xml")/items/item[partno = $pn]
where fn:count($i) >= 3
order by $pn
return 
   <well-supplied-item>
      <partno> {$pn} </partno>
      <avgprice> {fn:avg($i/price)} </avgprice>
   </well-supplied-item>

XQ.E29 - editorial

See Bug 6693

See Bug 6717

Description

State more explicitly that user-defined types in an imported schema add constructors for these types to the set of known function signatures.

History

17 Mar 2009: Proposed

24 Mar 2009: Accepted

Changes

  1. In C.1 Static Context Components (first table, first table body, eleventh row, fourth column):

    Replace the text:

    augmentable by module import and by function declaration in prolog

    With:

    augmentable by module import and by function declaration in prolog; augmentable by schema import (which adds constructor functions for user-defined types)
  2. In C.2 Dynamic Context Components (first table, first table body, sixth row, fourth column):

    Replace the text:

    augmentable by module import and by function declaration in prolog

    With:

    augmentable by module import and by function declaration in prolog; augmentable by schema import (which adds constructor functions for user-defined types)
  3. In 4.10 Schema Import (first paragraph, first termdef):

    Replace the text:

    [Definition] A schema import imports the element declarations, attribute declarations, and type definitions from a schema into the in-scope schema definitions.

    With:

    [Definition] A schema import imports the element declarations, attribute declarations, and type definitions from a schema into the in-scope schema definitions. For each user-defined atomic type in the schema, schema import also adds a corresponding constructor function.

XQ.E28 - substantive

See Bug 6716

Description

A new non-normative appendix designed to give guidance on the handling of modules.

History

17 Mar 2009: Proposed

24 Mar 2009: Accepted

Change

In (second inform-div1):

Insert after the text:

A Example Applications (Non-Normative)

This section contains examples of several important classes of queries that can be expressed using XQuery. The applications described here include joins across multiple data sources, grouping and aggregation, queries based on sequential relationships, recursive transformations, and selection of distinct combinations of values.

1 Joins

Joins, which combine data from multiple sources into a single result, are a very important type of query. In this section we will illustrate how several types of joins can be expressed in XQuery. We will base our examples on the following three documents:

  1. A document named parts.xml that contains many part elements; each part element in turn contains partno and description subelements.

  2. A document named suppliers.xml that contains many supplier elements; each supplier element in turn contains suppno and suppname subelements.

  3. A document named catalog.xml that contains information about the relationships between suppliers and parts. The catalog document contains many item elements, each of which in turn contains partno, suppno, and price subelements.

A conventional ("inner") join returns information from two or more related sources, as illustrated by the following example, which combines information from three documents. The example generates a "descriptive catalog" derived from the catalog document, but containing part descriptions instead of part numbers and supplier names instead of supplier numbers. The new catalog is ordered alphabetically by part description and secondarily by supplier name.

<descriptive-catalog>
   { 
     for $i in fn:doc("catalog.xml")/items/item,
         $p in fn:doc("parts.xml")/parts/part[partno = $i/partno],
         $s in fn:doc("suppliers.xml")/suppliers
                  /supplier[suppno = $i/suppno]
     order by $p/description, $s/suppname
     return
        <item>
           {
           $p/description,
           $s/suppname,
           $i/price
           }
        </item>
   }
</descriptive-catalog>

The previous query returns information only about parts that have suppliers and suppliers that have parts. An outer join is a join that preserves information from one or more of the participating sources, including elements that have no matching element in the other source. For example, a left outer join between suppliers and parts might return information about suppliers that have no matching parts.

The following query demonstrates a left outer join. It returns names of all the suppliers in alphabetic order, including those that supply no parts. In the result, each supplier element contains the descriptions of all the parts it supplies, in alphabetic order.

for $s in fn:doc("suppliers.xml")/suppliers/supplier
order by $s/suppname
return
   <supplier>
      { 
        $s/suppname,
        for $i in fn:doc("catalog.xml")/items/item
                 [suppno = $s/suppno],
            $p in fn:doc("parts.xml")/parts/part
                 [partno = $i/pno]
        order by $p/description
        return $p/description 
      }
   </supplier>

The previous query preserves information about suppliers that supply no parts. Another type of join, called a full outer join, might be used to preserve information about both suppliers that supply no parts and parts that have no supplier. The result of a full outer join can be structured in any of several ways. The following query generates a list of supplier elements, each containing nested part elements for the parts that it supplies (if any), followed by a list of part elements for the parts that have no supplier. This might be thought of as a "supplier-centered" full outer join. Other forms of outer join queries are also possible.

<master-list>
 {
    for $s in fn:doc("suppliers.xml")/suppliers/supplier
    order by $s/suppname
    return
        <supplier>
           { 
             $s/suppname,
             for $i in fn:doc("catalog.xml")/items/item
                     [suppno = $s/suppno],
                 $p in fn:doc("parts.xml")/parts/part
                     [partno = $i/partno]
             order by $p/description
             return
                <part>
                   {
                     $p/description,
                     $i/price
                   }
                </part> 
           }
        </supplier> 
    ,
    (: parts that have no supplier :)
    <orphan-parts>
       { for $p in fn:doc("parts.xml")/parts/part
         where fn:empty(fn:doc("catalog.xml")/items/item
               [partno = $p/partno] )
         order by $p/description
         return $p/description 
       }
    </orphan-parts>
 }
</master-list>

The previous query uses an element constructor to enclose its output inside a master-list element. The concatenation operator (",") is used to combine the two main parts of the query. The result is an ordered sequence of supplier elements followed by an orphan-parts element that contains descriptions of all the parts that have no supplier.

2 Grouping

Many queries involve forming data into groups and applying some aggregation function such as fn:count or fn:avg to each group. The following example shows how such a query might be expressed in XQuery, using the catalog document defined in the previous section.

This query finds the part number and average price for parts that have at least 3 suppliers.

for $pn in fn:distinct-values(
      fn:doc("catalog.xml")/items/item/partno)
let $i := fn:doc("catalog.xml")/items/item[partno = $pn]
where fn:count($i) >= 3
order by $pn
return 
   <well-supplied-item>
      <partno> {$p} </partno>
      <avgprice> {fn:avg($i/price)} </avgprice>
   </well-supplied-item>

The fn:distinct-values function in this query eliminates duplicate part numbers from the set of all part numbers in the catalog document. The result of fn:distinct-values is a sequence in which order is not significant.

Note that $pn, bound by a for clause, represents an individual part number, whereas $i, bound by a let clause, represents a set of items which serves as argument to the aggregate functions fn:count($i) and fn:avg($i/price). The query uses an element constructor to enclose each part number and average price in a containing element called well-supplied-item.

The method illustrated above generalizes easily to grouping by more than one data value. For example, consider a census document containing a sequence of person elements, each with subelements named state, job, and income. A census analyst might need to prepare a report listing the average income for each combination of state and job. This report might be produced using the following query:

for $s in fn:distinct-values(
        fn:doc("census.xml")/census/person/state),
    $j in fn:distinct-values(
        fn:doc("census.xml")/census/person/job)
let $p := fn:doc("census.xml")/census/person
        [state = $s and job = $j]
order by $s, $j
return 
   if (fn:exists($p)) then
      <group>
         <state> {$s} </state>
         <job> {$j} </job>
         <avgincome> {fn:avg($p/income)} </avgincome>
      </group>
   else ()

The if-then-else expression in the above example prevents generation of groups that contain no data. For example, the census data may contain some persons who live in Nebraska, and some persons whose job is Deep Sea Fisherman, but no persons who live in Nebraska and have the job of Deep Sea Fisherman. If output groups are desired for all possible combinations of states and jobs, the if-then-else expression can be omitted from the query. In this case, the output may include "empty" groups such as the following:

<group>
   <state>Nebraska</state>
   <job>Deep Sea Fisherman</job>
   <avgincome/>
</group>

3 Queries on Sequence

XQuery uses the << and >> operators to compare nodes based on document order. Although these operators are quite simple, they can be used to express complex queries for XML documents in which sequence is meaningful. The first two queries in this section involve a surgical report that contains procedure, incision, instrument, action, and anesthesia elements.

The following query returns all the action elements that occur between the first and second incision elements inside the first procedure. The original document order among these nodes is preserved in the result of the query.

let $proc := /report/procedure[1]
for $i in $proc//action
where $i >> ($proc//incision)[1]
   and $i << ($proc//incision)[2]
return $i

It is worth noting here that document order is defined in such a way that a node is considered to precede its descendants in document order. In the surgical report, an action is never part of an incision, but an instrument is. Since the >> operator is based on document order, the predicate $i >> ($proc//incision)[1] is true for any instrument element that is a descendant of the first incision element in the first procedure.

For some queries, it may be helpful to define a function that can test whether a node precedes another node without being its ancestor. The following function returns true if its first operand precedes its second operand but is not an ancestor of its second operand; otherwise it returns false:

declare function local:precedes($a as node(), $b as node()) 
   as boolean
   {
      $a << $b
        and
      fn:empty($a//node() intersect $b) 
   };

Similarly, a local:follows function could be written:

declare function local:follows($a as node(), $b as node()) 
   as boolean
   {
      $a >> $b
        and
      fn:empty($b//node() intersect $a) 
   };

Using the local:precedes function, we can write a query that finds instrument elements between the first two incisions, excluding from the query result any instrument that is a descendant of the first incision:

let $proc := /report/procedure[1]
for $i in $proc//instrument
where local:precedes(($proc//incision)[1], $i)
   and local:precedes($i, ($proc//incision)[2])
return $i

The following query reports incisions for which no prior anesthesia was recorded in the surgical report. Since an anesthesia is never part of an incision, we can use << instead of the less-efficient local:precedes function:

for $proc in /report/procedure
where some $i in $proc//incision satisfies
         fn:empty($proc//anesthesia[. << $i])
return $proc

In some documents, particular sequences of elements may indicate a logical hierarchy. This is most commonly true of HTML. The following query returns the introduction of an XHTML document, wrapping it in a div element. In this example, we assume that an h2 element containing the text "Introduction" marks the beginning of the introduction, and the introduction continues until the next h2 or h1 element, or the end of the document, whichever comes first.

let $intro := //h2[text()="Introduction"],
    $next-h := //(h1|h2)[. >> $intro][1]
return
   <div>
     {
       $intro,
       if (fn:empty($next-h))
         then //node()[. >> $intro]
         else //node()[. >> $intro and . << $next-h]
     }
   </div>

Note that the above query makes explicit the hierarchy that was implicit in the original document. In this example, we assume that the h2 element containing the text "Introduction" has no subelements.

4 Recursive Transformations

Occasionally it is necessary to scan over a hierarchy of elements, applying some transformation at each level of the hierarchy. In XQuery this can be accomplished by defining a recursive function. In this section we will present two examples of such recursive functions.

Suppose that we need to compute a table of contents for a given document by scanning over the document, retaining only elements named section or title, and preserving the hierarchical relationships among these elements. For each section, we retain subelements named section or title; but for each title, we retain the full content of the element. This might be accomplished by the following recursive function:

declare function local:sections-and-titles($n as node()) as node()?
   {
   if (fn:local-name($n) = "section")
   then element
          { fn:local-name($n) }
          { for $c in $n/* return local:sections-and-titles($c) }
   else if (fn:local-name($n) = "title")
   then $n
   else ( )
   };

The "skeleton" of a given document, containing only its sections and titles, can then be obtained by invoking the local:sections-and-titles function on the root node of the document, as follows:

local:sections-and-titles(fn:doc("cookbook.xml"))

As another example of a recursive transformation, suppose that we wish to scan over a document, transforming every attribute named color to an element named color, and every element named size to an attribute named size. This can be accomplished by the following recursive function (note that the element constructor in case $e generates attributes before child elements):

declare function local:swizzle($n as node()) as node() 
  { 
   typeswitch($n)
     case $a as attribute(color)
       return element color { fn:string($a) } 
     case $es as element(size) 
       return attribute size { fn:string($es) } 
     case $e as element() 
       return element 
         { fn:local-name($e) } 
         { for $c in 
             ($e/@* except $e/@color,     (: attr -> attr :)
              $e/size,                    (: elem -> attr :)
              $e/@color,                  (: attr -> elem :)
              $e/node() except $e/size )  (: elem -> elem :)
           return local:swizzle($c) }
     case $d as document-node() 
       return document 
         { for $c in $d/* return local:swizzle($c) } 
     default return $n 
  };

The transformation can be applied to a whole document by invoking the local:swizzle function on the root node of the document, as follows:

local:swizzle(fn:doc("plans.xml"))

5 Selecting Distinct Combinations

It is sometimes necessary to search through a set of data to find all the distinct combinations of a given list of properties. For example, an input data set might consist of a large set of order elements, each of which has the same basic structure, as illustrated by the following example:

<order>
   <date>2003-10-15</date>
   <product>Dress Shirt</product>
   <size>M</size>
   <color>Blue</color>
   <supplier>Fashion Trends</supplier>
   <quantity>50</quantity>
</order>

From this data set, a user might wish to find all the distinct combinations of product, size, and color that occur together in an order. The following query returns this list, enclosing each distinct combination in a new element named option:

for $p in fn:distinct-values(/orders/order/product),
    $s in fn:distinct-values(/orders/order/size),
    $c in fn:distinct-values(/orders/order/color)
    order by $p, $s, $c
    return
       if (fn:exists(/orders/order[product eq $p
                and size eq $s and color eq $c]))
       then
          <option>
             <product>{$p}</product>
             <size>{$s}</size>
             <color>{$c}</color>
          </option>
       else ()

The following:

A Guidance for Handling of Modules (Non-Normative)

This specification gives considerable flexibility to implementations in the way that modules are implemented, in particular, in the way that module URIs and their location URIs are interpreted. This flexibility is intentional, because XQuery implementations are designed to operate in a wide variety of environments, and some of those environments impose constraints. Nevertheless, in the interests of interoperability, the Working Group hopes that it will be useful to offer some suggestions for how implementations might choose to interpret the specification, in the absence of implementation factors that make a different interpretation necessary.

Module URIs

Generally, Module URIs should be treated in the same way as other namespace URIs.

Query authors should use a string that is a legal absolute IRI. Implementors should accept any string of Unicode characters. Module URIs should be compared using the Unicode codepoint collation rather than any concept of semantic equivalence.

Implementations may provide mechanisms allowing the module URI to be used as input to a process that delivers the module as a resource, for example a catalog, module repository, or URI resolver. For interoperability, such mechanisms should not prevent the user from choosing an arbitrary URI for naming a module.

Similarly, implementations may perform syntactic transformations on the module URI to obtain the names of related resources, for example to implement a convention relating the name or location of compiled code to the module URI; but again, such mechanisms should not prevent the user from choosing an arbitrary module URI.

As with other namespace URIs, common practice is often to use module URIs whose scheme is "http" and whose authority part uses a DNS domain name under the control of the user.

The specifications allow, and some users might consider it good practice, for the module URI of a function library to be the same as the namespace URI of the XML vocabulary manipulated by the functions in that library.

Multiple Modules with the same Module URI

The specifications allow several different modules with the same Module URI to participate in a query.

Although other interpretations are possible, it is suggested that in such cases implementations should require the names of global variables and functions to be unique within the query as a whole: that is, if two modules with the same module URI participate in a query, the names of their global variables and functions should not overlap.

If one module contains an "import module" declaration for the module URI M, then all global variables and functions declared in participating modules whose module URI is M should be accessible in the importing module, regardless whether the participation of the imported module was directly due to this "import module" declaration.

There should only be one instance of a global variable with any given name. For example, if a global variable V is initialized using an element constructor, then there should only be one instance of this element, even if the module in which V is declared is imported by several other modules.

(A different approach to this might be used in an environment where a group of modules can be compiled as a unit; in such cases a module used within the compiled unit might be considered distinct from an instance of the same module imported from elsewhere in the query.)

Location URIs

The term "location URIs" is used here to refer to the URIs in the "at" clause of an "import module" declaration.

Products should (by default or at user option) take account of all the location URIs in an "import module" declaration, treating each location URI as a reference to a module with the specified module URI. Location URIs should be made absolute with respect to the static base URI of the query module containing the "import module" declaration where they appear. The mapping from location URIs to module source code or compiled code MAY be done in any way convenient to the implementation. If possible given the product's architecture, security requirements, etc, the product should allow this to fetch the source code of the module to use the standard web mechanisms for dereferencing URIs in standard schemes such as the "http" URI scheme.

When the same absolutized location URI is used more than once, either in the same "import module" declaration or in different "import module" declarations within the same query, a single copy of the resource containing the module should be loaded. When different absolutized location URIs are used, each should result in a single module being loaded, unless the implementation is able to determine that the different URIs are references to the same resource. No error due to duplicate variable or functions names should arise from the same module being imported more than once, so long as the absolute location URI is the same in each case.

By default, implementations should report a static error if a location URI cannot be resolved. However, this is not intended to disallow recovery strategies being used if appropriate.

Cycles

It is not an error to have a cycle in the import graph, either at the level of module URIs or at the level of location URIs. The only rules concerning cycles affect the relationships between functions and variables defined in different modules.

XQ.E27 - substantive

See Bug 5351

Description

Specifies that leading and trailing whitespace are stripped from a PITarget specified in a SequenceType of form processing-instruction(PITarget) before it is tested to see if it is a syntactically valid NCName.

Also makes the description of the error introduced in E12 more precise. If accepted, this supersedes E12.

History

17 Mar 2009: Proposed

24 Mar 2009: Accepted

Change

In 2.5.4.2 Matching an ItemType and an Item (first bulleted list, sixth item, first paragraph):

Replace the text:

processing-instruction(N) matches any processing-instruction node whose name (called its "PITarget" in XML) is equal to N, where N is an NCName.

With:

processing-instruction(N) matches any processing-instruction node whose PITarget is equal to fn:normalize-space(N). If fn:normalize-space(N) is not in the lexical space of NCName, a type error is raised [err:XPTY0004]

XQ.E26 - substantive

See Bug 5876

Description

Corrects the description of precedence with respect to parentheses and square brackets.

History

17 Mar 2009: Proposed

24 Mar 2009: Accepted

Changes

  1. In A.4 Precedence Order (first paragraph):

    Replace the text:

    The grammar in A.1 EBNF normatively defines built-in precedence among the operators of XQuery. These operators are summarized here to make clear the order of their precedence from lowest to highest. Operators that have a lower precedence number cannot be contained by operators with a higher precedence number. The associativity column indicates the order in which operators of equal precedence in an expression are applied.

    With:

    The grammar in A.1 EBNF normatively defines built-in precedence among the operators of XQuery. These operators are summarized here to make clear the order of their precedence from lowest to highest. The associativity column indicates the order in which operators of equal precedence in an expression are applied.

  2. In A.4 Precedence Order (first table, twentieth row):

    Replace the text:

    19[ ], ( ), {}left-to-right

    With:

    19[ ]left-to-right
  3. Insert at the end of section A.4 Precedence Order

    The following:

    Note:

    Parentheses can be used to override the operator precedence in the usual way. Square brackets in an expression such as A[B] serve two roles: they act as an operator causing B to be evaluated once for each item in the value of A, and they act as parentheses enclosing the expression B.

    Curly braces in an expression such as validate{E} or ordered{E} perform a similar bracketing role to the parentheses in a function call, but with the difference in most cases that E is an Expr rather than ExprSingle, meaning that it can use the comma operator.

XQ.E25 - editorial

See Bug 6557

Description

Adds a missing word to an error description.

History

17 Mar 2009: Proposed

24 Mar 2009: Accepted

Change

In F Error Conditions (first error-list, thirty-third error):

Replace the text:

err:XQST0034

It is a static error if multiple functions declared or imported by a module have the number of arguments and their expanded QNames are equal (as defined by the eq operator).

With:

err:XQST0034

It is a static error if multiple functions declared or imported by a module have the same number of arguments and their expanded QNames are equal (as defined by the eq operator).

XQ.E24 - substantive

See Bug 5727

Description

Clarifications on parsing leading / in XPath expressions.

History

22 Feb 2009: Proposed

24 Mar 2009: Accepted

Change

In A.1.2 Extra-grammatical Constraints (first constraint):

Replace the text:

Constraint: leading-lone-slash

A single slash may appear either as a complete path expression or as the first part of a path expression in which it is followed by a RelativePathExpr, which can take the form of a NameTest ("*" or a QName). In contexts where operators like "*", "union", etc., can occur, parsers may have difficulty distinguishing operators from NameTests. For example, without lookahead the first part of the expression "/ * 5", for example is easily taken to be a complete expression, "/ *", which has a very different interpretation (the child nodes of "/").

To reduce the need for lookahead, therefore, if the token immediately following a slash is "*" or a keyword, then the slash must be the beginning, but not the entirety, of a PathExpr (and the following token must be a NameTest, not an operator).

A single slash may be used as the left-hand argument of an operator by parenthesizing it: (/) * 5. The expression 5 * /, on the other hand, is legal without parentheses.

With:

Constraint: leading-lone-slash

A single slash may appear either as a complete path expression or as the first part of a path expression in which it is followed by a RelativePathExpr. In some cases, the next token after the slash is insufficient to allow a parser to distinguish these two possibilities: the * token and keywords like union could be either an operator or a NameTest , and the < token could be either an operator or the start of a DirectConstructor. For example, without lookahead the first part of the expression / * 5 is easily taken to be a complete expression, / *, which has a very different interpretation (the child nodes of /).

Therefore to reduce the need for lookahead, if the token immediately following a slash can form the start of a RelativePathExpr, then the slash must be the beginning of a PathExpr, not the entirety of it.

A single slash may be used as the left-hand argument of an operator by parenthesizing it: (/) * 5. The expression 5 * /, on the other hand, is legal without parentheses.

XQ.E23 - editorial

See Bug 6287

Description

Defines the meaning of "undefined" for Data Model properties.

History

22 Feb 2009: Proposed

24 Mar 2009: Accepted

Change

In 2 Basics (third paragraph):

Replace the text:

[Definition] In the data model, a value is always a sequence. [Definition] A sequence is an ordered collection of zero or more items. [Definition] An item is either an atomic value or a node. [Definition] An atomic value is a value in the value space of an atomic type, as defined in [XML Schema] . [Definition] A node is an instance of one of the node kinds defined in [XQuery/XPath Data Model (XDM)] . Each node has a unique node identity, a typed value, and a string value. In addition, some nodes have a name. The typed value of a node is a sequence of zero or more atomic values. The string value of a node is a value of type xs:string. The name of a node is a value of type xs:QName.

With:

[Definition] In the data model, a value is always a sequence. [Definition] A sequence is an ordered collection of zero or more items. [Definition] An item is either an atomic value or a node. [Definition] An atomic value is a value in the value space of an atomic type, as defined in [XML Schema] . [Definition] A node is an instance of one of the node kinds defined in [XQuery/XPath Data Model (XDM)] . Each node has a unique node identity, a typed value, and a string value. In addition, some nodes have a name. The typed value of a node is a sequence of zero or more atomic values. The string value of a node is a value of type xs:string. The name of a node is a value of type xs:QName. [Definition] In certain situations a value is said to be undefined (for example, the value of the context item, or the typed value of an element node). This term indicates that the property in question has no value and that any attempt to use its value results in an error.

XQ.E22 - substantive

See Bug 6027

Description

Specifies conformance criteria for syntax extensions.

History

22 Feb 2009: Proposed

24 Mar 2009: Accepted

Changes

  1. Insert after section 5.3 Data Model Conformance

    The following:

    1 Syntax Extensions

    Any syntactic extensions to XQuery are implementation-defined. The effect of syntactic extensions, including their error behavior, is implementation-defined. Syntactic extensions may be used without restriction to modify the semantics of a XQuery expression.

  2. In D Implementation-Defined Items (first numbered list, eighteenth item):

    Insert after the text:

    20

    Limits on ranges of values for various data types, as enumerated in 5.3 Data Model Conformance.

    The following:

    • Syntactic extensions to XQuery, including both their syntax and semantics, as discussed in 5.4 Syntax Extensions.

XQ.E21 - substantive

See Bug 5347

Description

Allows (and encourages) the use of XML 1.0 editions newer than the Third Edition.

History

22 Feb 2009: Proposed

24 Mar 2009: Accepted

Changes

  1. In E.1 Normative References (first bibliography, seventh bibliographic reference):

    Replace the text:

    XML 1.0
    World Wide Web Consortium. Extensible Markup Language (XML) 1.0. (Third Edition) W3C Recommendation. See http://www.w3.org/TR/REC-xml

    With:

    XML 1.0
    World Wide Web Consortium. Extensible Markup Language (XML) 1.0. W3C Recommendation. See http://www.w3.org/TR/REC-xml. The edition of XML 1.0 must be no earlier than the Third Edition; the edition used is implementation-defined, but we recommend that implementations use the latest version.
  2. In D Implementation-Defined Items (first numbered list, sixth item):

    Replace the text:

    6

    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.

    With:

    • 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. If the implementation is based on the rules of [XML 1.0] , the edition used must be at least Third Edition; the edition used is implementation-defined, but we recommend that implementations use the latest version.

XQ.E20 - editorial

See Bug 5984

Description

Corrects a list of examples of primitive atomic types.

History

10 Sep 2008: Proposed

7 Oct 2008: Accepted

Change

In 2.5.1 Predefined Schema Types (first numbered list, fifth item, first paragraph):

Replace the text:

[Definition] xs:anyAtomicType is an atomic type that includes all atomic values (and no values that are not atomic). Its base type is xs:anySimpleType from which all simple types, including atomic, list, and union types, are derived. All primitive atomic types, such as xs:integer, xs:string, and xs:untypedAtomic, have xs:anyAtomicType as their base type.

With:

[Definition] xs:anyAtomicType is an atomic type that includes all atomic values (and no values that are not atomic). Its base type is xs:anySimpleType from which all simple types, including atomic, list, and union types, are derived. All primitive atomic types, such as xs:decimal and xs:string, have xs:anyAtomicType as their base type.

XQ.E19 - substantive

See Bug 4463

Description

Specifies rules that prevent the redefinition of certain predefined namespace prefixes.

History

23 Jul 2008: Proposed

7 Oct 2008: Accepted

Changes

  1. In 3.7.1.2 Namespace Declaration Attributes (first bulleted list, third item):

    Replace the text:

    • It is a static error [err:XQST0070] if a namespace declaration attribute binds a namespace URI to the predefined prefix xmlns. It is also a static error [err:XQST0070] if a namespace declaration attribute binds a namespace URI other than http://www.w3.org/XML/1998/namespace to the prefix xml, or binds a prefix other than xml to the namespace URI http://www.w3.org/XML/1998/namespace.

    With:

    • It is a static error [err:XQST0070] if a namespace declaration attribute attempts to do any of the following:

      • Bind the prefix xml to some namespace URI other than http://www.w3.org/XML/1998/namespace.

      • Bind a prefix other than xml to the namespace URI http://www.w3.org/XML/1998/namespace.

      • Bind the prefix xmlns to any namespace URI.

      • Bind a prefix to the namespace URI http://www.w3.org/2000/xmlns/.

  2. In 3.7.3.1 Computed Element Constructors (fourth paragraph):

    Insert before the text:

    The content expression of a computed element constructor (if present) is processed in exactly the same way as an enclosed expression in the content of a direct element constructor, as described in Step 1e of 3.7.1.3 Content. The result of processing the content expression is a sequence of nodes called the content sequence. If the content expression is absent, the content sequence is an empty sequence.

    The following:

    A dynamic error is raised [ERROR 0096 NOT FOUND] if the node-name of the constructed element node has any of the following properties:

    • Its namespace prefix is xmlns.

    • Its namespace URI is http://www.w3.org/2000/xmlns/.

    • Its namespace prefix is xml and its namespace URI is not http://www.w3.org/XML/1998/namespace.

    • Its namespace prefix is other than xml and its namespace URI is http://www.w3.org/XML/1998/namespace.

  3. In 3.7.3.2 Computed Attribute Constructors (fourth paragraph):

    Replace the text:

    The node-name property of the constructed attribute (an expanded QName) is checked as follows: If its URI part is http://www.w3.org/2000/xmlns/ (corresponding to namespace prefix xmlns) or if it is in no namespace and its local name is xmlns, a dynamic error [err:XQDY0044] is raised.

    With:

    A static error is raised [ERROR 0044 NOT FOUND] if the node-name of the constructed attribute node has any of the following properties:

    • Its namespace prefix is xmlns.

    • It has no namespace prefix and its local name is xmlns.

    • Its namespace URI is http://www.w3.org/2000/xmlns/.

    • Its namespace prefix is xml and its namespace URI is not http://www.w3.org/XML/1998/namespace.

    • Its namespace prefix is other than xml and its namespace URI is http://www.w3.org/XML/1998/namespace.

  4. In 4.12 Namespace Declaration (fifth paragraph):

    Replace the text:

    The namespace prefix specified in a namespace declaration must not be xml or xmlns [err:XQST0070], and must not be the same as any namespace prefix bound in the same module by a module import, schema import, module declaration, or another namespace declaration [err:XQST0033].

    With:

    The namespace prefix specified in a namespace declaration must not be xml or xmlns [err:XQST0070]. The namespace URI specified in a namespace declaration must not be http://www.w3.org/XML/1998/namespace or http://www.w3.org/2000/xmlns/ [err:XQST0070]. The namespace prefix specified in a namespace declaration must not be the same as any namespace prefix bound in the same module by a module import, schema import, module declaration, or another namespace declaration [err:XQST0033].

  5. In F Error Conditions (first error-list, forty-third error):

    Replace the text:

    err:XQDY0044

    It is a dynamic error if the node-name property of the node constructed by a computed attribute constructor is in the namespace http://www.w3.org/2000/xmlns/ (corresponding to namespace prefix xmlns), or is in no namespace and has local name xmlns.

    With:

    err:XQST0044

    It is a static error the node-name of a node constructed by a computed attribute constructor has any of the following properties:

    • Its namespace prefix is xmlns.

    • It has no namespace prefix and its local name is xmlns.

    • Its namespace URI is http://www.w3.org/2000/xmlns/.

    • Its namespace prefix is xml and its namespace URI is not http://www.w3.org/XML/1998/namespace.

    • Its namespace prefix is other than xml and its namespace URI is http://www.w3.org/XML/1998/namespace.

  6. In F Error Conditions (first error-list, sixty-ninth error):

    Replace the text:

    err:XQST0070

    A static error is raised if a namespace URI is bound to the predefined prefix xmlns, or if a namespace URI other than http://www.w3.org/XML/1998/namespace is bound to the prefix xml, or if the prefix xml is bound to a namespace URI other than http://www.w3.org/XML/1998/namespace.

    With:

    err:XQST0070

    A static error is raised if one of the predefined prefixes xml or xmlns appears in a namespace declaration, or if any of the following conditions is statically detected in any expression or declaration:

    • The prefix xml is bound to some namespace URI other than http://www.w3.org/XML/1998/namespace.

    • A prefix other than xml is bound to the namespace URI http://www.w3.org/XML/1998/namespace.

    • The prefix xmlns is bound to any namespace URI.

    • A prefix other than xmlns is bound to the namespace URI http://www.w3.org/2000/xmlns/.

  7. In F Error Conditions (first error-list, ninety-second error):

    Insert after the text:

    err:XQST0093

    It is a static error to import a module M1 if there exists a sequence of modules M1 ... Mi ... M1 such that each module directly depends on the next module in the sequence (informally, if M1 depends on itself through some chain of module dependencies.)

    The following:

    err:XQDY0096

    It is a dynamic error the node-name of a node constructed by a computed element constructor has any of the following properties:

    • Its namespace prefix is xmlns.

    • Its namespace URI is http://www.w3.org/2000/xmlns/.

    • Its namespace prefix is xml and its namespace URI is not http://www.w3.org/XML/1998/namespace.

    • Its namespace prefix is other than xml and its namespace URI is http://www.w3.org/XML/1998/namespace.

XQ.E18 - substantive

See Bug 5223

Description

Specifies that general comparisons cast an untyped operand to the primitive base type of the other operand rather than to the most specific type of the other operand.

History

22 Jul 2008: Proposed

7 Oct 2008: Accepted

Change

In 3.5.2 General Comparisons (starting at first numbered list, second item, first numbered list, first item):

Replace the text:

a

If one of the atomic values is an instance of xs:untypedAtomic and the other is an instance of a numeric type, then the xs:untypedAtomic value is cast to the type xs:double.

b

If one of the atomic values is an instance of xs:untypedAtomic and the other is an instance of xs:untypedAtomic or xs:string, then the xs:untypedAtomic value (or values) is (are) cast to the type xs:string.

c

If one of the atomic values is an instance of xs:untypedAtomic and the other is not an instance of xs:string, xs:untypedAtomic, or any numeric type, then the xs:untypedAtomic value is cast to the dynamic type of the other value.

With:

a

If both atomic values are instances of xs:untypedAtomic, then the values are cast to the type xs:string.

b

If exactly one of the atomic values is an instance of xs:untypedAtomic, it is cast to a type depending on the other value's dynamic type T according to the following rules, in which V denotes the value to be cast:

  1. If T is a numeric type or is derived from a numeric type, then V is cast to xs:double.

  2. If T is xs:dayTimeDuration or is derived from xs:dayTimeDuration, then V is cast to xs:dayTimeDuration.

  3. If T is xs:yearMonthDuration or is derived from xs:yearMonthDuration, then V is cast to xs:yearMonthDuration.

  4. In all other cases, V is cast to the primitive base type of T.

Note:

The special treatment of the duration types is required to avoid errors that may arise when comparing the primitive type xs:duration with any duration type.

XQ.E17 - substantive

See Bug 5290

Description

Specifies that, in the order-by clause of a FLWOR expression, a user-specified collation applies only if the value of the ordering expression is of type xs:string or is convertible to xs:string.

History

21 Jul 2008: Proposed

7 Oct 2008: Accepted

Change

In 3.8.3 Order By and Return Clauses (starting at fifth paragraph):

Replace the text:

When two orderspec values are compared to determine their relative position in the ordering sequence, the greater-than relationship is defined as follows:

With:

For the purpose of determining their relative position in the ordering sequence, the greater-than relationship between two orderspec values W and V is defined as follows:

XQ.E16 - editorial

See Bug 5471

Description

Deletes unnecessary reference to RFC2396 from Normative References. This item is never referenced in the normative text.

History

18 Jul 2008: Proposed

7 Oct 2008: Accepted

Change

In E.1 Normative References (first bibliography, second bibliographic reference):

Delete the text:

RFC2396
T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax. IETF RFC 2396. See http://www.ietf.org/rfc/rfc2396.txt.

XQ.E15 - editorial

See Bug 5261

Description

Removes references to error code FORG0001 from description of cast expression. Replaces them with a reference to Functions and Operators for normative description of error behavior.

History

18 Jul 2008: Proposed

7 Oct 2008: Accepted

Change

In 3.12.3 Cast (first numbered list, fourth item, first numbered list, third item):

Replace the text:

c

cast is supported if the target type is a non-primitive atomic type and the input type is xs:string or xs:untypedAtomic. The input value is first converted to a value in the lexical space of the target type by applying the whitespace normalization rules for the target type (as defined in [XML Schema] ); a dynamic error [err:FORG0001] is raised if the resulting lexical value does not satisfy the pattern facet of the target type. The lexical value is then converted to the value space of the target type using the schema-defined rules for the target type; a dynamic error [err:FORG0001] is raised if the resulting value does not satisfy all the facets of the target type.

With:

c

cast is supported if the target type is a non-primitive atomic type and the input type is xs:string or xs:untypedAtomic. The input value is first converted to a value in the lexical space of the target type by applying the whitespace normalization rules for the target type (as defined in [XML Schema] ). The lexical value is then converted to the value space of the target type using the schema-defined rules for the target type. If the input value fails to satisfy some facet of the target type, a dynamic error may be raised as specified in [XQuery 1.0 and XPath 2.0 Functions and Operators] .

XQ.E14 - editorial

See Bug 5224

Description

Calls attention to the entry in Appendix C that defines the initial values for context item, position, and size, which can be referenced in initializing expressions in variable declarations.

History

18 Jul 2008: Proposed

24 Mar 2009: Accepted

Change

In 4.14 Variable Declaration (third paragraph):

Replace the text:

[Definition] If a variable declaration includes an expression, the expression is called an initializing expression. The initializing expression for a given variable must be evaluated before the evaluation of any expression that references the variable. The static context for an initializing expression includes all functions that are declared or imported anywhere in the Prolog, but it includes only those variables and namespaces that are declared or imported earlier in the Prolog than the variable that is being initialized.

With:

[Definition] If a variable declaration includes an expression, the expression is called an initializing expression. The initializing expression for a given variable must be evaluated before the evaluation of any expression that references the variable. The static context for an initializing expression includes all functions that are declared or imported anywhere in the Prolog, but it includes only those variables and namespaces that are declared or imported earlier in the Prolog than the variable that is being initialized. The context item, position, and size in the dynamic context of the initializing expression have initial values as described in C.2 Dynamic Context Components.

XQ.E13 - substantive

See Bug 5083

Description

Disallows enclosed expressions inside a namespace declaration attribute, and clarifies handling of consecutive curly-braces, consecutive single-quotes, and consecutive double-quotes inside attribute values.

History

18 Jul 2008: Proposed

7 Oct 2008: Accepted

Changes

  1. In 3.7.1.1 Attributes (first numbered list, first item):

    Replace the text:

    1

    Each consecutive sequence of literal characters in the attribute content is treated as a string containing those characters. Attribute value normalization is then applied to normalize whitespace and expand character references and predefined entity references. An XQuery processor that supports XML 1.0 uses the rules for attribute value normalization in Section 3.3.3 of [XML 1.0] ; an XQuery processor that supports XML 1.1 uses the rules for attribute value normalization in Section 3.3.3 of [XML 1.1] . In either case, the normalization rules are applied as though the type of the attribute were CDATA (leading and trailing whitespace characters are not stripped.) The choice between XML 1.0 and XML 1.1 rules is implementation-defined.

    With:

    1

    Each consecutive sequence of literal characters in the attribute content is treated as a string containing those characters, with the following exceptions:

    1. Each occurrence of two consecutive { characters is replaced by a single { character.

    2. Each occurrence of two consecutive } characters is replaced by a single } character.

    3. Each occurrence of two consecutive " characters is replaced by a single " character.

    4. Each occurrence of two consecutive ' characters is replaced by a single ' character.

    Attribute value normalization is then applied to normalize whitespace and expand character references and predefined entity references. An XQuery processor that supports XML 1.0 uses the rules for attribute value normalization in Section 3.3.3 of [XML 1.0] ; an XQuery processor that supports XML 1.1 uses the rules for attribute value normalization in Section 3.3.3 of [XML 1.1] . In either case, the normalization rules are applied as though the type of the attribute were CDATA (leading and trailing whitespace characters are not stripped.) The choice between XML 1.0 and XML 1.1 rules is implementation-defined.

  2. In 3.7.1.2 Namespace Declaration Attributes (second paragraph):

    Replace the text:

    [Definition] A namespace declaration attribute is used inside a direct element constructor. Its purpose is to bind a namespace prefix or to set the default element/type namespace for the constructed element node, including its attributes. Syntactically, a namespace declaration attribute has the form of an attribute with namespace prefix xmlns, or with name xmlns and no namespace prefix. The value of a namespace declaration attribute must be a URILiteral; otherwise a static error is raised [err:XQST0022]. All the namespace declaration attributes of a given element must have distinct names [err:XQST0071]. Each namespace declaration attribute is processed as follows:

    With:

    [Definition] A namespace declaration attribute is used inside a direct element constructor. Its purpose is to bind a namespace prefix or to set the default element/type namespace for the constructed element node, including its attributes. Syntactically, a namespace declaration attribute has the form of an attribute with namespace prefix xmlns, or with name xmlns and no namespace prefix. All the namespace declaration attributes of a given element must have distinct names [err:XQST0071]. Each namespace declaration attribute is processed as follows:

  3. In 3.7.1.2 Namespace Declaration Attributes (first bulleted list, first item):

    Insert before the text:

    • The local part of the attribute name is interpreted as a namespace prefix and the value of the attribute is interpreted as a namespace URI. This prefix and URI are added to the statically known namespaces of the constructor expression (overriding any existing binding of the given prefix), and are also added as a namespace binding to the in-scope namespaces of the constructed element. If the namespace URI is a zero-length string and the implementation supports [XML Names 1.1] , any existing namespace binding for the given prefix is removed from the in-scope namespaces of the constructed element and from the statically known namespaces of the constructor expression. If the namespace URI is a zero-length string and the implementation does not support [XML Names 1.1] , a static error is raised [err:XQST0085]. It is implementation-defined whether an implementation supports [XML Names] or [XML Names 1.1] .

    The following:

    • The value of the namespace declaration attribute (a DirAttributeValue) is processed as follows. If the DirAttributeValue contains an EnclosedExpr, a static error is raised [err:XQST0022]. Otherwise, it is processed as described in rule 1 of 3.7.1.1 Attributes. An implementation MAY raise a static error [err:XQST0046] if the resulting value is of nonzero length and is not in the lexical space of xs:anyURI. The resulting value is used as the namespace URI in the following rules.

  4. In 3.7.1.2 Namespace Declaration Attributes (first bulleted list, first item):

    Replace the text:

    • The local part of the attribute name is interpreted as a namespace prefix and the value of the attribute is interpreted as a namespace URI. This prefix and URI are added to the statically known namespaces of the constructor expression (overriding any existing binding of the given prefix), and are also added as a namespace binding to the in-scope namespaces of the constructed element. If the namespace URI is a zero-length string and the implementation supports [XML Names 1.1] , any existing namespace binding for the given prefix is removed from the in-scope namespaces of the constructed element and from the statically known namespaces of the constructor expression. If the namespace URI is a zero-length string and the implementation does not support [XML Names 1.1] , a static error is raised [err:XQST0085]. It is implementation-defined whether an implementation supports [XML Names] or [XML Names 1.1] .

    With:

    • If the prefix of the attribute name is xmlns, then the local part of the attribute name is interpreted as a namespace prefix. This prefix and the namespace URI are added to the statically known namespaces of the constructor expression (overriding any existing binding of the given prefix), and are also added as a namespace binding to the in-scope namespaces of the constructed element. If the namespace URI is a zero-length string and the implementation supports [XML Names 1.1] , any existing namespace binding for the given prefix is removed from the in-scope namespaces of the constructed element and from the statically known namespaces of the constructor expression. If the namespace URI is a zero-length string and the implementation does not support [XML Names 1.1] , a static error is raised [err:XQST0085]. It is implementation-defined whether an implementation supports [XML Names] or [XML Names 1.1] .

  5. In 3.7.1.2 Namespace Declaration Attributes (first bulleted list, second item):

    Replace the text:

    • If the name of the namespace declaration attribute is xmlns with no prefix, the value of the attribute is interpreted as a namespace URI. This URI specifies the default element/type namespace of the constructor expression (overriding any existing default), and is added (with no prefix) to the in-scope namespaces of the constructed element (overriding any existing namespace binding with no prefix). If the namespace URI is a zero-length string, the default element/type namespace of the constructor expression is set to "none," and any no-prefix namespace binding is removed from the in-scope namespaces of the constructed element.

    With:

    • If the name of the namespace declaration attribute is xmlns with no prefix, then the namespace URI specifies the default element/type namespace of the constructor expression (overriding any existing default), and is added (with no prefix) to the in-scope namespaces of the constructed element (overriding any existing namespace binding with no prefix). If the namespace URI is a zero-length string, the default element/type namespace of the constructor expression is set to "none," and any no-prefix namespace binding is removed from the in-scope namespaces of the constructed element.

XQ.E12 - substantive

See Bug 5351

See Bug 6559

Description

Specifies that an error results if the PITarget specified in a SequenceType of form processing-instruction(PITarget) is not a syntactically valid NCName.

History

16 Jul 2008: Proposed

Change

In 2.5.4.2 Matching an ItemType and an Item (first bulleted list, sixth item, third paragraph):

Insert after the text:

For backward compatibility with XPath 1.0, the PITarget of a processing instruction may also be expressed as a string literal, as in this example: processing-instruction("xml-stylesheet").

The following:

If the specified PITarget is not a syntactically valid NCName, a type error is raised [err:XPTY0004].

XQ.E11 - editorial

See Bug 5207

Description

Clarifies behavior of node constructors when base-URI in static context is undefined.

History

14 Jul 2008: Proposed

7 Oct 2008: Accepted

Change

In 4.5 Base URI Declaration (fifth paragraph):

Replace the text:

It is not intrinsically an error if this process fails to establish an absolute base URI; however, the base URI in the static context is then undefined, and any attempt to use its value may result in an error [err:XPST0001].

With:

It is not intrinsically an error if this process fails to establish an absolute base URI; however, the base URI in the static context is then undefined. When the base URI in the static context is undefined, any attempt to use its value to resolve a relative URI reference will result in an error [err:XPST0001]. When the base URI of a constructed node is taken from the base URI in the static context and the latter is undefined, then the base-uri property of the constructed node is empty."

XQ.E10 - editorial

See Bug 5035

Description

Clarifies that the default initial static type of the context item is undefined.

History

27 Sep 2007: Proposed

20 Nov 2007: Accepted

Change

In C.1 Static Context Components (first table, first table body, tenth row, second column):

Replace the text:

none (raises error on access)

With:

Undefined (raises error on access)

XQ.E9 - substantive

See Bug 4443

Description

Specifies that, in a computed attribute constructor, if the QName of the constructed attribute has a namespace URI but no prefix, an implementation-dependent prefix is generated.

History

27 Sep 2007: Proposed

20 Nov 2007: Accepted

Change

In 3.7.3.2 Computed Attribute Constructors (first numbered list, second item):

Replace the text:

2

If the atomized value of the name expression is of type xs:QName, that expanded QName (including its prefix) is used as the node-name property of the constructed attribute node.

With:

2

If the atomized value of the name expression is of type xs:QName:

  1. If the expanded QName returned by the atomized name expression has a namespace URI but has no prefix, it is given an implementation-dependent prefix.

    Note:

    This step is necessary because the default namespace does not apply to attributes. Therefore any attribute name that has a namespace URI must also have a prefix.

  2. The resulting expanded QName (including its prefix) is used as the node-name property of the constructed attribute node.

XQ.E8 - substantive

See Bug 4418

Description

Deletes error code XQST0073, because it is redundant to error code XQST0093.

History

9 Oct 2007: Proposed

20 Nov 2007: Accepted

Changes

  1. In 4.11 Module Import (sixth paragraph):

    Replace the text:

    A module may import its own target namespace (this is interpreted as importing an implementation-defined set of other modules that share its target namespace.) However, it is a static error [err:XQST0073] if the graph of module imports contains a cycle (that is, if there exists a sequence of modules M1 ... Mn such that each Mi imports Mi+1 and Mn imports M1), unless all the modules in the cycle share a common namespace.

    With:

    A module may import its own target namespace (this is interpreted as importing an implementation-defined set of other modules that share its target namespace.)

  2. In F Error Conditions (first error-list, seventy-second error):

    Delete the text:

    err:XQST0073

    It is a static error if the graph of module imports contains a cycle (that is, if there exists a sequence of modules M1 ... Mn such that each Mi imports Mi+1 and Mn imports M1), unless all the modules in the cycle share a common namespace.

XQ.E7 - substantive

See Bug 4353

Description

In Section 3.13 (Validate Expression), Rule 3c, deletes "Identity-constraint Satisfied" from the list of rules that are not applied during validation. This rule must be applied.

History

27 Sep 2007: Proposed

20 Nov 2007: Accepted

Change

In 3.13 Validate Expressions (first numbered list, third item, first numbered list, third item):

Replace the text:

c

If the operand node is an element node, the validation rules named "Validation Root Valid (ID/IDREF)" and "Identity-constraint Satisfied" are not applied. This means that document-level constraints relating to uniqueness and referential integrity are not enforced.

With:

c

If the operand node is an element node, the validation rule named "Validation Root Valid (ID/IDREF)" is not applied. This means that document-level constraints relating to uniqueness and referential integrity are not enforced.

XQ.E6 - substantive

See Bug 4321

Description

Tightens the rules for the in-scope schema definitions that must be present in an importing module. For example, if the imported module contains a function definition that includes a parameter of type schema-element(EN) and that function is referenced in the importing module, then the importing module must have an in-scope element declaration for EN.

History

16 Oct 2007: Proposed

20 Nov 2007: Accepted

Changes

  1. In 4.11 Module Import (seventh paragraph):

    Replace the text:

    It is a static error [err:XQST0036] to import a module if the importing module's in-scope schema types do not include definitions for the schema type names that appear in the declarations of variables and functions (whether in an argument type or return type) that are present in the imported module and are referenced in the importing module.

    With:

    It is a static error [err:XQST0036] to import a module if the in-scope schema definitions of the importing module do not include all of the following:

    1. An in-scope schema type for each type-name that appears:

      1. in the type of a variable that is declared in the imported module and referenced in the importing module, OR

      2. in a parameter-type or result-type of a function that is declared in the imported module and referenced in the importing module.

    2. An in-scope element declaration for each element-name EN such that:

      1. schema-element(EN) appears in the declared type of a variable in the imported module, and that variable is referenced in the importing module, OR

      2. schema-element(EN) appears in a parameter-type or result-type of a function declared in the imported module, and that function is referenced in the importing module.

    3. An in-scope attribute declaration for each attribute-name AN such that:

      1. schema-attribute(AN) appears in the declared type of a variable in the imported module, and that variable is referenced in the importing module, OR

      2. schema-attribute(AN) appears in a parameter-type or result-type of a function declared in the imported module, and that function is referenced in the importing module.

  2. In F Error Conditions (first error-list, thirty-fifth error):

    Replace the text:

    err:XQST0036

    It is a static error to import a module if the importing module's in-scope schema types do not include definitions for the schema type names that appear in the declarations of variables and functions (whether in an argument type or return type) that are present in the imported module and are referenced in the importing module.

    With:

    err:XQST0036

    It is a static error to import a module if the in-scope schema definitions of the importing module do not include all of the following:

    1. An in-scope schema type for each type-name that appears:

      1. in the type of a variable that is declared in the imported module and referenced in the importing module, OR

      2. in a parameter-type or result-type of a function that is declared in the imported module and referenced in the importing module.

    2. An in-scope element declaration for each element-name EN such that:

      1. schema-element(EN) appears in the declared type of a variable in the imported module, and that variable is referenced in the importing module, OR

      2. schema-element(EN) appears in a parameter-type or result-type of a function declared in the imported module, and that function is referenced in the importing module.

    3. An in-scope attribute declaration for each attribute-name AN such that:

      1. schema-attribute(AN) appears in the declared type of a variable in the imported module, and that variable is referenced in the importing module, OR

      2. schema-attribute(AN) appears in a parameter-type or result-type of a function declared in the imported module, and that function is referenced in the importing module.

XQ.E5 - substantive

See Bug 4873

Description

Clarifies the conditions under which a castable expression may raise an error.

History

19 Sep 2007: Proposed

20 Nov 2007: Accepted

Change

In 3.12.4 Castable (second paragraph):

Replace the text:

The expression V castable as T returns true if the value V can be successfully cast into the target type T by using a cast expression; otherwise it returns false. The castable expression can be used as a predicate to avoid errors at evaluation time. It can also be used to select an appropriate type for processing of a given value, as illustrated in the following example:

With:

The expression E castable as T returns true if the result of evaluating E can be successfully cast into the target type T by using a cast expression; otherwise it returns false. If evaluation of E fails with a dynamic error, the castable expression as a whole fails. The castable expression can be used as a predicate to avoid errors at evaluation time. It can also be used to select an appropriate type for processing of a given value, as illustrated in the following example:

XQ.E4 - substantive

See Bug 4446

Description

Adds more details to the rules defining permissible expression rewrites for optimization and other purposes.

History

19 Sep 2007: Proposed

20 Nov 2007: Accepted

Changes

  1. In 2.3.4 Errors and Optimization (twelfth paragraph):

    Replace the text:

    For a variety of reasons, including optimization, implementations are free to rewrite expressions into equivalent expressions. Other than the raising or not raising of errors, the result of evaluating an equivalent expression must be the same as the result of evaluating the original expression. Expression rewrite is illustrated by the following examples.

    With:

    For a variety of reasons, including optimization, implementations may rewrite expressions into a different form. There are a number of rules that limit the extent of this freedom:

    • Other than the raising or not raising of errors, the result of evaluating a rewritten expression must conform to the semantics defined in this specification for the original expression.

      Note:

      This allows an implementation to return a result in cases where the original expression would have raised an error, or to raise an error in cases where the original expression would have returned a result. The main cases where this is likely to arise in practice are (a) where a rewrite changes the order of evaluation, such that a subexpression causing an error is evaluated when the expression is written one way and is not evaluated when the expression is written a different way, and (b) where intermediate results of the evaluation cause overflow or other out-of-range conditions.

      Note:

      This rule does not mean that the result of the expression will always be the same in non-error cases as if it had not been rewritten, because there are many cases where the result of an expression is to some degree implementation-dependent or implementation-defined.

    • Conditional and typeswitch expressions must not raise a dynamic error in respect of subexpressions occurring in a branch that is not selected, and must not return the value delivered by a branch unless that branch is selected. Thus, the following example must not raise a dynamic error if the document abc.xml does not exist:

      if (doc-available('abc.xml')) then doc('abc.xml') else ()
    • As stated earlier, an expression must not be rewritten to dispense with a required cardinality check: for example, string-length(//title) must raise an error if the document contains more than one title element.

    • Expressions must not be rewritten in such a way as to create or remove static errors. For example, there is a rule that in casting a string to a QName the operand must be a string literal. This rule applies to the original expression and not to any rewritten form of the expression.

    Expression rewrite is illustrated by the following examples.

  2. In 2.3.4 Errors and Optimization (second bulleted list, second item, second paragraph):

    Replace the text:

    To avoid unexpected errors caused by expression rewrite, tests that are designed to prevent dynamic errors should be expressed using conditional or typeswitch expressions. Conditional and typeswitch expressions raise only dynamic errors that occur in the branch that is actually selected. Thus, unlike the previous example, the following example cannot raise a dynamic error if @x is not castable into an xs:date:

    With:

    To avoid unexpected errors caused by expression rewrite, tests that are designed to prevent dynamic errors should be expressed using conditional or typeswitch expressions. For example, the above expression can be written as follows:

XQ.E3 - editorial

See Bug 4868

Description

For valid syntax, adds parentheses to the expansion for leading "/" and leading "//" in a path expression.

History

10 Aug 2007: Proposed

20 Nov 2007: Accepted

Changes

  1. In 3.2 Path Expressions (third paragraph):

    Replace the text:

    A "/" at the beginning of a path expression is an abbreviation for the initial step fn:root(self::node()) treat as document-node()/ (however, if the "/" is the entire path expression, the trailing "/" is omitted from the expansion.) The effect of this initial step is to begin the path at the root node of the tree that contains the context node. If the context item is not a node, a type error is raised [err:XPTY0020]. At evaluation time, if the root node above the context node is not a document node, a dynamic error is raised [err:XPDY0050].

    With:

    A "/" at the beginning of a path expression is an abbreviation for the initial step (fn:root(self::node()) treat as document-node())/ (however, if the "/" is the entire path expression, the trailing "/" is omitted from the expansion.) The effect of this initial step is to begin the path at the root node of the tree that contains the context node. If the context item is not a node, a type error is raised [err:XPTY0020]. At evaluation time, if the root node above the context node is not a document node, a dynamic error is raised [err:XPDY0050].

  2. In 3.2 Path Expressions (fourth paragraph):

    Replace the text:

    A "//" at the beginning of a path expression is an abbreviation for the initial steps fn:root(self::node()) treat as document-node()/descendant-or-self::node()/ (however, "//" by itself is not a valid path expression [err:XPST0003].) The effect of these initial steps is to establish an initial node sequence that contains the root of the tree in which the context node is found, plus all nodes descended from this root. This node sequence is used as the input to subsequent steps in the path expression. If the context item is not a node, a type error is raised [err:XPTY0020]. At evaluation time, if the root node above the context node is not a document node, a dynamic error is raised [err:XPDY0050].

    With:

    A "//" at the beginning of a path expression is an abbreviation for the initial steps (fn:root(self::node()) treat as document-node())/descendant-or-self::node()/ (however, "//" by itself is not a valid path expression [err:XPST0003].) The effect of these initial steps is to establish an initial node sequence that contains the root of the tree in which the context node is found, plus all nodes descended from this root. This node sequence is used as the input to subsequent steps in the path expression. If the context item is not a node, a type error is raised [err:XPTY0020]. At evaluation time, if the root node above the context node is not a document node, a dynamic error is raised [err:XPDY0050].

XQ.E2 - substantive

See Bug 3637

Description

Reverses the order of Rules 1 and 2 in XQuery Section 3.7.3.1, Computed Element Constructors (processing of content sequence). Also reverses the order of Rules 1 and 2 in Section 3.7.3.3, Document Node Constructors. These changes are necessary in order to cause document nodes to be replaced by their children before adjacent text nodes are merged.

History

10 Aug 2007: Proposed

20 Nov 2007: Accepted

Changes

  1. In 3.7.3.1 Computed Element Constructors (starting at second numbered list, first item):

    Replace the text:

    1

    Adjacent text nodes in the content sequence are merged into a single text node by concatenating their contents, with no intervening blanks. After concatenation, any text node whose content is a zero-length string is deleted from the content sequence.

    2

    If the content sequence contains a document node, the document node is replaced in the content sequence by its children.

    With:

    1

    If the content sequence contains a document node, the document node is replaced in the content sequence by its children.

    2

    Adjacent text nodes in the content sequence are merged into a single text node by concatenating their contents, with no intervening blanks. After concatenation, any text node whose content is a zero-length string is deleted from the content sequence.

  2. In 3.7.3.3 Document Node Constructors (starting at first numbered list, first item):

    Replace the text:

    1

    Adjacent text nodes in the content sequence are merged into a single text node by concatenating their contents, with no intervening blanks. After concatenation, any text node whose content is a zero-length string is deleted from the content sequence.

    2

    If the content sequence contains a document node, the document node is replaced in the content sequence by its children.

    With:

    1

    If the content sequence contains a document node, the document node is replaced in the content sequence by its children.

    2

    Adjacent text nodes in the content sequence are merged into a single text node by concatenating their contents, with no intervening blanks. After concatenation, any text node whose content is a zero-length string is deleted from the content sequence.

XQ.E1 - substantive

See Bug 4151

Description

Specifies that error XQTY0086 applies to copied attribute nodes as well as copied element nodes, including copied attribute nodes that have no parent. The error is raised when construction-mode calls for the type of a QName to be preserved, but copy-namespaces-mode does not preserve the namespace binding that is needed by the QName.

History

23 Oct 2007: Proposed

20 Nov 2007: Accepted

Changes

  1. In 3.7.1.3 Content (first numbered list, first item, first numbered list, fifth item, first numbered list, second item, first numbered list, fourth item, first numbered list, first item):

    Replace the text:

    I

    If copy-namespaces mode specifies preserve, all in-scope-namespaces of the original element are retained in the new copy. If copy-namespaces mode specifies no-preserve, the new copy retains only those in-scope namespaces of the original element that are used in the names of the element and its attributes. It is a type error [err:XQTY0086] in this case if the typed value of the copied element or of any of its attributes is namespace-sensitive. [Definition] A value is namespace-sensitive if it includes an item whose dynamic type is xs:QName or xs:NOTATION or is derived by restriction from xs:QName or xs:NOTATION.

    Note:

    Error [err:XQTY0086] can occur only if construction mode is preserve, since otherwise the typed value of the copied node is never namespace-sensitive.

    With:

    I

    If copy-namespaces mode specifies preserve, all in-scope-namespaces of the original element are retained in the new copy. If copy-namespaces mode specifies no-preserve, the new copy retains only those in-scope namespaces of the original element that are used in the names of the element and its attributes.

  2. In 3.7.1.3 Content (first numbered list, first item, first numbered list, fifth item, first numbered list, second item, first numbered list, fifth item):

    Insert before the text:

    E

    When an element or processing instruction node is copied, its base-uri property is set to be the same as that of its new parent, with the following exception: if a copied element node has an xml:base attribute, its base-uri property is set to the value of that attribute, resolved (if it is relative) against the base-uri property of the new parent node.

    The following:

    E

    An enclosed expression in the content of an element constructor may cause one or more existing nodes to be copied. Type error [err:XQTY0086] is raised in the following cases:

    1. An element node is copied, and the typed value of the element node or one of its attributes is namespace-sensitive, and construction mode is preserve, and copy-namespaces mode is no-preserve.

    2. An attribute node is copied but its parent element node is not copied, and the typed value of the copied attribute node is namespace-sensitive, and construction mode is preserve.

    [Definition] A value is namespace-sensitive if it includes an item whose dynamic type is xs:QName or xs:NOTATION or is derived by restriction from xs:QName or xs:NOTATION.

    Note:

    The rationale for error [err:XQTY0086] is as follows: It is not possible to preserve the type of a QName without also preserving the namespace binding that defines the prefix of the QName.


Index by affected section

XQ.E28

2 Basics

XQ.E23

2.3.4 Errors and Optimization

XQ.E4

2.5.1 Predefined Schema Types

XQ.E20

2.5.4.2 Matching an ItemType and an Item

XQ.E12 XQ.E27

3.2 Path Expressions

XQ.E3

3.5.2 General Comparisons

XQ.E18

3.7.1.1 Attributes

XQ.E13

3.7.1.2 Namespace Declaration Attributes

XQ.E13 XQ.E19

3.7.1.3 Content

XQ.E1

3.7.3.1 Computed Element Constructors

XQ.E2 XQ.E19

3.7.3.2 Computed Attribute Constructors

XQ.E9 XQ.E19

3.7.3.3 Document Node Constructors

XQ.E2

3.8.3 Order By and Return Clauses

XQ.E17

3.12.3 Cast

XQ.E15

3.12.4 Castable

XQ.E5

3.13 Validate Expressions

XQ.E7

4.5 Base URI Declaration

XQ.E11

4.10 Schema Import

XQ.E29

4.11 Module Import

XQ.E6 XQ.E8

4.12 Namespace Declaration

XQ.E19

4.14 Variable Declaration

XQ.E14

5.3 Data Model Conformance

XQ.E22

A.1.2 Extra-grammatical Constraints

XQ.E24

A.4 Precedence Order

XQ.E26

C.1 Static Context Components

XQ.E10 XQ.E29

C.2 Dynamic Context Components

XQ.E29

D Implementation-Defined Items

XQ.E21 XQ.E22

E.1 Normative References

XQ.E16 XQ.E21

F Error Conditions

XQ.E6 XQ.E8 XQ.E19 XQ.E25

I.2 Grouping

XQ.E30

Index by Bugzilla entry

Bug #3637: XQ.E2

Bug #4151: XQ.E1

Bug #4321: XQ.E6

Bug #4353: XQ.E7

Bug #4418: XQ.E8

Bug #4443: XQ.E9

Bug #4446: XQ.E4

Bug #4463: XQ.E19

Bug #4868: XQ.E3

Bug #4873: XQ.E5

Bug #5035: XQ.E10

Bug #5083: XQ.E13

Bug #5207: XQ.E11

Bug #5223: XQ.E18

Bug #5224: XQ.E14

Bug #5261: XQ.E15

Bug #5290: XQ.E17

Bug #5347: XQ.E21

Bug #5351: XQ.E12 XQ.E27

Bug #5471: XQ.E16

Bug #5727: XQ.E24

Bug #5876: XQ.E26

Bug #5984: XQ.E20

Bug #6027: XQ.E22

Bug #6287: XQ.E23

Bug #6557: XQ.E25

Bug #6559: XQ.E12

Bug #6693: XQ.E29

Bug #6716: XQ.E28

Bug #6717: XQ.E29

Bug #6737: XQ.E30

Index by construct

- (minus): XQ.E2

/ (at start of path): XQ.E3

// (at start of path): XQ.E3

| (union): XQ.E2

castable as: XQ.E5

computed attribute constructor: XQ.E9

import module: XQ.E6 XQ.E8

validate: XQ.E7

Index by error-code

XQST0036: XQ.E6

XQST0073: XQ.E8

XQST0093: XQ.E8