Copyright © 2007-2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document addresses errors in the XQuery 1.0 and XPath 2.0 Formal Semantics 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 XSL Working Group and 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.
Substantive corrections are proposed by the XSL Working Group and 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 [FSerrata] 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/.
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.
Errata
FS.E062 Don't define the static type of the namespace axis.
FS.E061 Fix unsoundness of 'data on' judgment.
FS.E060 Fix behaviour of following-sibling axis re attribute nodes.
FS.E059 Fix various bugs in the 'union interpretation' rules.
FS.E058 Fix the static typing for ValidateExpr.
FS.E057 Fix the static typing for fs:convert-operand().
FS.E056 Fix italicization in C.2 [Mapping of Overloaded Internal Functions].
FS.E055 Change wording re fs:convert-operand in 4.5.2 [General Comparisons].
FS.E054 Fix typo in 8.4 [Judgments for FLWOR and other expressions on sequences].
FS.E053 Fix incorrect references to standard functions/operators.
FS.E052 Change some wording in 4.7.1 [Direct Element Constructors].
FS.E051 Correctly render metavariables in mapping subscripts.
FS.E050 Fix typo in 4.2.1 [Steps].
FS.E049 Minor changes in 4.1.5 [Function Calls] / Dynamic Evaluation.
FS.E048 Change some wording in 4.1.5 [Function Calls] / Static Type Analysis.
FS.E047 Change some wording in 4.1.5 [Function Calls] / Normalization.
FS.E046 Fix typos in 4 [Expressions].
FS.E045 Fix typo in 3.2.2 [Normalization mapping rules].
FS.E044 Fix typo in 2.5 [Functions and operators].
FS.E043 Fix typos in 2.4.4 [Top level definitions].
FS.E042 In the production for Definitions, add a semicolon after each Definition.
FS.E041 Fix typos in 2.4.3 [Content models].
FS.E040 Fix typos in 2.4.1 [XML Schema and the [XPath/XQuery] Type System].
FS.E039 Fix typo in 2.3.2 [Examples of values].
FS.E038 Fix typos in 2.3.1 [Formal values].
FS.E037 Fix typo in 2.1.4 [Notations for inference rules].
FS.E036 Introduce Formal symbol OptDerivation.
FS.E035 Fix typo in 5.14 [Variable Declaration].
FS.E034 Adjust the formatting of a rule in 8.2.2.2 [Dynamic semantics of axes].
FS.E033 Fix the static typing for numeric and aggregate functions.
FS.E032 Rework the rules for CastableExpr to avoid raising type errors (and fix various other problems).
FS.E031 Don't use the "interleave with empty text nodes" technique for attribute constructors.
FS.E030 Fix cross-reference in 4.7.3.4.
FS.E029 Don't use the "interleave with empty text nodes" technique for element constructors.
FS.E028 Call fn:boolean() in normalization of Where clause
FS.E027 Provide (non-default) static typing for fn:not().
FS.E026 Fix small errors in section 7.2.4 [The fn:boolean function].
FS.E025 For internal function fs:div, correct the result type in the Binary Operators table.
FS.E024 Introduce fs:item-at() function.
FS.E023 ElementNameOrWildcard and AttributeNameOrWildcard do not derive empty.
FS.E022 Make the static typing of processing-instructions consistent with their dynamic typing.
FS.E021 Avoid loss of type information in normalized path expressions.
FS.E020 Correct errors in examples in section 2.4.4.
FS.E019 Correct a normalization error in section 4.3.2 Filter Expressions.
FS.E018 Correct various errors in section 8.2.3.1.1.
FS.E017 Update the "Processing Model" diagram.
FS.E016 For internal function fs:idiv, correct the operand types and supporting op: function given in the Binary Operators table.
FS.E015 Fix some small errors in section 8.4.
FS.E014 Fix small errors in section 7.2.3.
FS.E013 Fix small errors in sections 7.2.1 and 7.2.2.
FS.E012 Static Type Analysis must allow for empty text nodes introduced during normalization of direct element constructors.
FS.E011 Correct/simplify/complete the Normalization rules defining []ElementContent and []AttributeContent, and simplify the corresponding Dynamic Evaluation rules.
FS.E010 Clean up due to the removal of op:anyURI-equal from the F+O spec.
FS.E009 Fix some errors in the productions for FunctionSig and TypeList.
FS.E008 Fix a bug in the normalization of function calls.
FS.E007 Fix miscellaneous small errors in section 5.
FS.E006 Fix problems involving the domains of statEnv.funcType and dynEnv.funcDefn: Although section 3.1.1 declares the domain of statEnv.funcType to be (expanded-QName, arity), some inference rules neglect the arity.
FS.E005 Put 'Expr' in parentheses when it occurs as a function argument.
FS.E004 Fix typo in function signature.
FS.E003 Complete the changes entailed by adding a local-namespaces component to the Core CompElemConstructor.
FS.E002 Both Core and Formal grammars had symbols 'NamespaceBinding' and 'NamespaceBindings'.
FS.E001 Make normalization of DirAttributeValue more explicit.
Indexes
See Bug 5452
Don't define the static type of the namespace axis.
23 Oct 2008: Proposed
24 Feb 2009: Accepted
6 Mar 2009: Issued
In 8.2.2.1.6 Inference rules for the namespace axis / Semantics, replace:
with:
This document does not specify inference rules for the namespace axis (which is allowed, though deprecated, in XPath 2.0, and is not allowed in XQuery 1.0). Implementations choosing to support the namespace axis will need to define an additional node kind for namespace nodes in the type hierarchy, and to add the appropriate inference rules.
See Bug 4273
Fix unsoundness of 'data on' judgment.
7 Feb 2009: Proposed
17 Feb 2009: Accepted
17 Feb 2009: Issued
In 7.2.6 The fn:data function / Static Type Analysis, replace:
When applied to an element type
whose type
annotationXQ denotes a complex type
of mixed content, the data
on filter returns xs:untypedAtomic.
|
|||
|
|
|||
| statEnv |- data on ElementType : xs:untypedAtomic |
The data on filter is not defined on any element type whose type annotationXQ denotes a complex type of complex content and therefore applying data on to such a node raises a static error.
with:
For any element node whose
type
annotationXQ is a complex type with
element-only content, the typed-value is undefined, and applying
fn:data to such a node raises a type error.
Consequently, the data
on judgment is not defined on any element type whose
type
annotationXQ denotes a complex type
of element-only content. Attempting to apply data on to such a type raises a type
error.
Because we can derive complex
types with element-only content from complex types with
mixed content (including xs:anyType), the
data on judgment is
also not defined on any element type whose type
annotationXQ is a complex type of
mixed content (other than xs:untyped, which is handled
above). Attempting to satisfy the data on judgment for such a type will fail,
and the processor will raise a type error.
See Bug 6538
Fix behaviour of following-sibling axis re attribute nodes.
7 Feb 2009: Proposed
11 Feb 2009: Accepted
16 Feb 2008: Issued
In 4.2.1.1 Axes / Normalization / rule 1, replace:
with:
In 4.2.1.1 Axes / Normalization / rule 2, replace:
with:
See Bug 4189
Fix various bugs in the 'union interpretation' rules.
2 Feb 2009: Proposed
10 Feb 2009: Accepted
16 Feb 2009: Issued
In 8.1.9 Type expansion, replace:
The judgment takes a type name and computes the union of all types derived from the given type. ... The judgment depends on the extended with union interpretation of judgment to recursively compute all derived types.
with:
The judgment takes a type name and computes the union of all types derived from the given type. ... The judgment depends on the union interpretation of judgment to recursively compute all derived types.
In 8.1.9 Type expansion / Semantics / rule 2, replace:
| statEnv.typeDefn(expanded-QName) = define type TypeName extends BaseTypeName OptMixed { Type1 } |
| statEnv |- Type2 is Type1 extended with union interpretation of TypeName |
| statEnv |- OptMixed Type2 adjusts to Type3 |
with:
| statEnv.typeDefn(expanded-QName) = Definition |
| statEnv |- union interpretation of Definition is TypeU |
| statEnv |- TypeU adjusts to Type3 |
In 8.1.9 Type expansion / Semantics / rule 3, replace:
statEnv.typeDefn(expanded-QName) = define type
xs:untyped extends xs:anyType { Type1
}
|
with:
statEnv.typeDefn(expanded-QName) = define type
xs:untyped restricts xs:anyType { Type1
}
|
In 8.1.10 Union interpretation of derived types / Notation, replace:
The judgment
holds when the type Type2 is the expansion of the type name TypeName with definition Type1 to include all types derived by extension and restriction from the given type name. This rule is recursive, because each type name itself may have other type names that are derived from it. The recursive rules traverse the entire derivation tree, identifying every type name derived from the original type name.
with:
The judgment
holds when the type TypeU is the union of all types derived (directly and indirectly, by extension and restriction) from the type defined by Definition.
In 8.1.10 Union interpretation of derived types / Semantics, replace:
|
||
|
|
||
| statEnv |- Type0 is Type0 extended with union interpretation of TypeName0 |
|
||||||||||||||
|
|
||||||||||||||
| statEnv |- Type1 is Type0 extended with union interpretation of TypeName0 |
with:
|
|||||||||
|
|
|||||||||
|
The auxilliary judgment
looks "up" the type hierarchy to find out what OptDerivation contributes to the content model of a derived type. It is defined as follows:
|
||||
|
|
||||
|
|
|
||
|
|
|
||
|
The auxiliary judgment:
holds when Type2 is the result of making Type1 'mixed' or not, as determined by OptMixed. It is defined as follows:
|
|
||
|
Finally, the auxiliary judgment:
is defined informally: all type definitions in statEnv.typeDefn that involve "restricts TypeName" or "extends TypeName" are returned as a list (in arbitrary order) of Definitions.
and replace:
define type T1 { element a }
define type T2 extends T1 { element b }
(element a | element a, element b) is (element a) extended with union interpretation of T1
with:
define type T1 { element a }
define type T2 extends T1 { element b }
union interpretation of
define type T1 { element a }
is
(element a | element a, element b)
and replace:
(element a, (() | element b)) is (element a) extended with union interpretation of T1
with:
union interpretation of
define type T1 { element a }
is
(element a, (() | element b))
See Bug 5254
Fix the static typing for ValidateExpr.
1 Feb 2009: Proposed
3 Feb 2009: Accepted
15 Feb 2009: Issued
In 4.13 Validate Expressions / Static Type Analysis, replace:
Static typing of the validate operation is defined by the following rule. Note the use of a subtyping check to ensure that the type of the expression to validate is either an element or a well-formed document node (i.e., with only one root element and no text nodes). The type of the expression to validate may be a union of more than one element type. We apply the with mode judgment to each element type to determine the meaning of that element type with the given validation mode, which yields a new element type. The result type is the union over all new element types.
|
|||||||||||
|
|
|||||||||||
| statEnv |- validate ValidationMode { Expr } : Type1 |
with:
Static typing of the validate operation begins with the following rule. We infer the type of the argument expression, and ensure that it is consistent with a run-time argument that is either an element or a well-formed document node (i.e., with only one root element and no text nodes). Then we hand off the type and the validation mode to the validate judgment.
|
||||
|
|
||||
|
Because the type of the argument expression may be a union of multiple element and document types, the judgment:
extracts the prime type of the argument type, applies the validate item type judgment to each type in the union, and yields the union of the results.
|
||||||
|
|
||||||
|
The judgement
does a case analysis on the different item types that it can encounter.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|
||
|
See Bug 6160
Fix the static typing for fs:convert-operand().
14 Oct 2008: Proposed
11 Nov 2008: Accepted
15 Feb 2009: Issued
In 7.1.1 The fs:convert-operand function / Static Type Analysis, replace:
No conversion is needed unless
$actual is an instance of type xs:untypedAtomic.
|
||
|
|
||
statEnv |- (FS-URI,"convert-operand")(
Type1, Type2)
: Type1 |
Pairs of untyped atomic operands are converted to strings.
|
|||
|
|
|||
statEnv |- (FS-URI,"convert-operand")(
Type1, Type2)
:
xs:string · quantifier (Type1)
|
When an untyped operand is paired with a numeric operand, it is converted to xs:double.
|
|||
|
|
|||
statEnv |- (FS-URI,"convert-operand")(
Type1, Type2)
:
xs:double · quantifier (Type1)
|
Finally, an untyped atomic operand not dealt with by the above rules is converted to the type of the other operand.
|
||||
|
|
||||
statEnv |- (FS-URI,"convert-operand")(
Type1, Type2)
: Type2
· quantifier(Type1)
|
with:
To analyze a call to fs:convert-operand,
we extract the prime type of the static type of each of the two
arguments. (Each prime type will be a union of atomic types.) We
consider all possible pairs formed by taking one atomic type from
each prime type, apply the convert_operand judgment to each pair, form
the union of the results, and adjust that by the quantifier of the
first argument's type.
|
|||||||||||||
|
|
|||||||||||||
|
The auxiliary judgment:
is the static analog of the
fs:convert-operand
function. It is defined by the following rules.
No conversion is needed if the
first argument isn't an instance of type xs:untypedAtomic.
|
||
|
|
||
|
The remaining rules cover the
cases when the first argument is an instance of type
xs:untypedAtomic.
The outcome depends on the type of the second argument.
If the second argument is of type
xs:untypedAtomic or
xs:string, the first is converted to a string.
|
|||
|
|
|||
|
If the second argument is numeric,
the first is converted to xs:double.
|
|||
|
|
|||
|
Otherwise, the first argument is converted to the type of the second argument.
|
|||
|
|
|||
|
In 8.4 Judgments for FLWOR and other expressions on sequences / Semantics 1, insert:
Note
This function is typically used in judgments of the form:
In cases where prime(Type) = none, there may be
a temptation to bind FormalItemType
1 to none and n to
1. However, it is important to note that
none is not a FormalItemType, rather it is
equivalent to a union type with no member types. Thus, in such
cases, the proper way to satisfy the given judgment is to bind
n to 0.
See Bug 6007
Fix italicization in C.2 [Mapping of Overloaded Internal Functions].
1 Sep 2008: Proposed
1 Sep 2008: Accepted
1 Sep 2008: Issued
In C.2 Mapping of Overloaded Internal Functions / Notation 2 / rule 1, replace:
with:
In C.2 Mapping of Overloaded Internal Functions / Notation 2 / rule 2, replace:
with:
See Bug 4601
Change wording re fs:convert-operand in 4.5.2 [General Comparisons].
8 Jun 2007: Proposed
1 Sep 2008: Accepted
1 Sep 2008: Issued
In 4.5.2 General Comparisons / Normalization, replace:
The normalization rule for a general comparison expression first
atomizes each argument by applying fn:data
and then applies the
existentially quantified SomeExpr expression to each
sequence. The internal function fs:convert-operand
is applied to each pair of atomic values. If the first argument to
this function has type xs:untypedAtomic, then the
first argument is cast to type of the second argument. If the
second argument has type xs:untypedAtomic, the first
argument is cast to a string. The overloaded internal function corresponding to the
general comparison operator is then applied to the two converted
values.
with:
The normalization rule for a general comparison expression first
atomizes each argument by applying fn:data,
resulting in two sequences of atomic values. Two nested
some expressions then examine (potentially) every pair
of values (one value from each sequence). For each pair, the
internal function fs:convert-operand
is called twice; if either of the two values is of type xs:untypedAtomic, one of
the calls will cast it to a type determined by the other
value. The overloaded internal function corresponding to the
general comparison operator is then applied to the two converted
values.
See Bug 4593
Fix typo in 8.4 [Judgments for FLWOR and other expressions on sequences].
1 Jun 2007: Proposed
4 Jun 2007: Accepted
1 Sep 2008: Issued
In 8.4 Judgments for FLWOR and other expressions on sequences / Semantics 2, replace:
Note that prime(Type) · quantifier(Type) is always a super type of the original type Type I.e., prime(Type) · quantifier(Type) <: Type always holds.
with:
Note that prime(Type) · quantifier(Type) is always a super type of the original type Type I.e., Type <: prime(Type) · quantifier(Type) always holds.
See Bug 4447
Fix incorrect references to standard functions/operators.
3 Apr 2007: Proposed
16 Apr 2007: Accepted
1 Sep 2008: Issued
In 8.4 Judgments for FLWOR and other expressions on sequences / Introduction, replace:
[Definition: A prime type is a choice of item types.] This section defines two functions on types that compute the prime type of an arbitrary type, and approximate the occurrence of items in an arbitrary type. These type functions are used in the static semantics of many expressions, including "for", "some", and "every" expressions, and many functions, including "fn:unordered" and "fn:distinct" .
with:
[Definition: A prime type is a choice of item types.] This section defines two functions on types that compute the prime type of an arbitrary type, and approximate the occurrence of items in an arbitrary type. These type functions are used in the static semantics of many expressions, including "for", "some", and "every" expressions, and many functions, including "fn:unordered" and "fn:distinct-values".
In C.2 Mapping of Overloaded Internal Functions / Notation 2 / Binary Operators table, replace:
fs:minus(A, B) |
xs:date |
xs:date |
fn:subtract-dates(A, B) | xs:dayTimeDuration |
| ... | ||||
fs:minus(A, B) |
xs:time |
xs:time |
fn:subtract-times(A, B) | xs:dayTimeDuration |
| ... | ||||
fs:minus(A, B) |
xs:dateTime |
xs:dateTime |
fn:subtract-dateTimes(A, B) | xs:dayTimeDuration |
with:
fs:minus(A, B) |
xs:date |
xs:date |
op:subtract-dates(A, B) | xs:dayTimeDuration |
| ... | ||||
fs:minus(A, B) |
xs:time |
xs:time |
op:subtract-times(A, B) | xs:dayTimeDuration |
| ... | ||||
fs:minus(A, B) |
xs:dateTime |
xs:dateTime |
op:subtract-dateTimes(A, B) | xs:dayTimeDuration |
and replace:
fs:eq(A, B) |
xs:hexBinary |
xs:hexBinary |
op:hex-binary-equal(A, B) | xs:boolean |
fs:eq(A, B) |
xs:base64Binary |
xs:base64Binary |
op:base64-binary-equal(A, B) | xs:boolean |
| ... | ||||
fs:ne(A, B) |
xs:hexBinary |
xs:hexBinary |
fn:not(op:hex-binary-equal(A, B)) |
xs:boolean |
fs:ne(A, B) |
xs:base64Binary |
xs:base64Binary |
fn:not(op:base64-binary-equal(A, B)) |
xs:boolean |
with:
fs:eq(A, B) |
xs:hexBinary |
xs:hexBinary |
op:hexBinary-equal(A, B) | xs:boolean |
fs:eq(A, B) |
xs:base64Binary |
xs:base64Binary |
op:base64Binary-equal(A, B) | xs:boolean |
| ... | ||||
fs:ne(A, B) |
xs:hexBinary |
xs:hexBinary |
fn:not(op:hexBinary-equal(A, B)) |
xs:boolean |
fs:ne(A, B) |
xs:base64Binary |
xs:base64Binary |
fn:not(op:base64Binary-equal(A, B)) |
xs:boolean |
See Bug 3895
Change some wording in 4.7.1 [Direct Element Constructors].
30 Oct 2006: Proposed
31 Aug 2008: Accepted
31 Aug 2008: Issued
In 4.7.1 Direct Element Constructors / Introduction, replace:
The static and dynamic semantics of the direct forms of element and attribute constructors are specified on the equivalent computed element and attribute constructors.
with:
The static and dynamic semantics of the direct forms of element and attribute constructors are specified in terms of the equivalent computed element and attribute constructors.
In 4.7.1 Direct Element Constructors / Notation 1, replace:
The auxiliary mapping rules []ElementContent, []ElementContentUnit, []PartitionIntoUnits, and []DirCharsUnits are defined in this section and are used for the normalization of the content of direct element constructors.
with:
The auxiliary mapping rules []ElementContent, []ElementContentUnit, []PartitionIntoUnits, and []DirCharsUnit are defined in this section and are used for the normalization of the content of direct element constructors.
In 4.7.1 Direct Element Constructors / Notation 2, replace:
An element-content unit is either a maximal contiguous sequence of literal characters (including character references, escaped braces, and predefined entity references), an enclosed expression, a direct element constructor, an XML comment, or an XML processing instruction.
with:
An element-content unit is either a DirCharsUnit ( a maximal contiguous sequence of literal characters , CDataSections, character references, escaped braces, and predefined entity references), an enclosed expression, a direct element constructor, an XML comment, or an XML processing instruction.
In 4.7.1 Direct Element Constructors / Normalization, replace:
Adjacent element-content units are convenient because they permit arbitrary interleaving of text and atomic data.
with:
Adjacent element-content units permit arbitrary interleaving of text and atomic data.
and replace:
<date>{ xs:date("2003-03-18") }</date>
=
element date {
fs:item-sequence-to-node-sequence(
xs:date("2003-03-18")
)
}
<address>
<!-- Dizzy's address -->
{ 123 }-0A <street>Roosevelt Ave.</street> Flushing, NY { 11368 }
</address>
=
element address {
fs:item-sequence-to-node-sequence(
comment { " Dizzy's address "},
123,
text { "-0A "},
element street {"Roosevelt Ave."},
text { " Flushing, NY " },
11368
)
}
with:
<date>{ xs:date("2003-03-18") }</date>
=
element date {
fs:item-sequence-to-node-sequence(
xs:date("2003-03-18")
)
} {}
<address>
<!-- Dizzy's address -->
{ 123 }-0A <street>Roosevelt Ave.</street> Flushing, NY { 11368 }
</address>
=
element address {
fs:item-sequence-to-node-sequence(
comment { " Dizzy's address "},
123,
text { "-0A "},
element street {"Roosevelt Ave."} {},
text { " Flushing, NY " },
11368
)
} {}
and replace:
The following normalization rule takes the longest consecutive sequence of individual characters that include literal characters, escaped curly braces, character references, and predefined entity references and normalizes the character sequence as a text node containing the string of characters.
with:
The following normalization rule takes a maximal contiguous sequence of individual characters that include literal characters, CDataSections, escaped curly braces, character references, and predefined entity references and normalizes the character sequence as a text node containing the string of characters.
In 4.7.1 Direct Element Constructors / Normalization / rule 5, replace:
| [DirCharsUnit]ElementContentUnit |
| == |
| text { [ DirCharsUnit ]DirCharsUnits } |
with:
| [DirCharsUnit]ElementContentUnit |
| == |
| text { [ DirCharsUnit ]DirCharsUnit } |
In 4.7.1 Direct Element Constructors / Normalization, replace:
The application of []DirCharsUnits to DirCharsUnit is defined informally. It produces a string literal corresponding to the content of the DirCharsUnit, in boundary whitespace is processed and non-literal characters (CharRefs, PredefinedEntityRefs, CDataSections, and escaped-braces) are resolved according to the rules in Section 3.7.1.3 ContentXQ.
with:
The application of []DirCharsUnit to DirCharsUnit is defined informally. It produces a string literal corresponding to the content of the DirCharsUnit, in which boundary whitespace is processed as specified in Section 3.7.1.4 Boundary WhitespaceXQ, and non-literal characters (CharRefs, PredefinedEntityRefs, CDataSections, and escaped-braces) are resolved according to the rules in Section 3.7.1.3 ContentXQ.
In 4.7.1.4 Boundary Whitespace, replace:
Section
3.7.1.4 Boundary WhitespaceXQ
describes how whitespace is processed in element constructors
depending on the value of the boundary-space
declaration in the query prolog. The Formal Semantics assumes that
the rules for handling whitespace are applied by the (informally
defined) auxiliary rule []DirCharsUnits.
with:
Section
3.7.1.4 Boundary WhitespaceXQ
describes how whitespace is processed in element constructors
depending on the value of the boundary-space
declaration in the query prolog. The Formal Semantics assumes that
the rules for handling whitespace are applied by the (informally
defined) auxiliary rule []DirCharsUnit.
See Bug 6005
Correctly render metavariables in mapping subscripts.
31 Aug 2008: Proposed
31 Aug 2008: Accepted
31 Aug 2008: Issued
In
with:
In
with:
and replace:
with:
In 4.1.5 Function Calls / Normalization / rule 1, replace:
with:
In
with:
In
with:
In
with:
In
with:
In
with:
See Bug 3886
Fix typo in 4.2.1 [Steps].
30 Oct 2006: Proposed
30 Aug 2008: Accepted
30 Aug 2008: Issued
In 4.2.1 Steps / Dynamic Evaluation / rule 1 / premise 1, replace:
with:
See Bug 3885
Minor changes in 4.1.5 [Function Calls] / Dynamic Evaluation.
29 Oct 2006: Proposed
30 Aug 2008: Accepted
30 Aug 2008: Issued
In 4.1.5 Function Calls / Dynamic Evaluation / rule 3 / premise 3, replace:
with:
In 4.1.5 Function Calls / Dynamic Evaluation, replace:
The rule for evaluating an function imported from a module ...
with:
The rule for evaluating a function imported from a module ...
In 4.1.5 Function Calls / Dynamic Evaluation / rule 5 / premise 7, replace:
with:
In 4.1.5 Function Calls / Dynamic Evaluation, replace:
If the function is a built-in function (resp. special formal semantics function), the value returned by the function is the one specified in [Functions and Operators] (resp. [7 Additional Semantics of Functions] ).
with:
If the function is a built-in function (resp. special formal semantics function), the value returned by the function is the one specified in [Functions and Operators] (resp. [7.1 Formal Semantics Functions] or [C.2 Mapping of Overloaded Internal Functions]).
In 4.1.5 Function Calls / Dynamic Evaluation / rule 7, replace:
|
|||
|
|
|||
|
with:
|
|||
|
|
|||
|
In 4.1.5 Function Calls / Dynamic Evaluation / rule 8, replace:
|
|||
|
|
|||
|
with:
|
|||
|
|
|||
|
See Bug 3883
Change some wording in 4.1.5 [Function Calls] / Static Type Analysis.
29 Oct 2006: Proposed
30 Aug 2008: Accepted
30 Aug 2008: Issued
In 4.1.5 Function Calls / Static Type Analysis, replace:
Different sets of static typing rules are used to type check function calls depending on which of the following categories the belong to: ...
with:
Different sets of static typing rules are used to type check function calls depending on which of the following categories they belong to: ...
and replace:
The following two rules are common to all those categories, and are used to bootstrap type inference, by first looking-up the expanded QName for the function, then applying the appropriate set of static typing rules depending on the category in which the function is.
with:
The following two rules factor out the step (common to all those categories) of translating a type-inference judgment on syntactic objects (QName and Expri) into a type-inference judgment on semantic objects (expanded-QName and Typei).
and replace:
The two following rules look up the function in the static environment and check that some signature for the function satisfies the following constraint: the type of each actual argument is a subtype of some type that can be promoted to the type of the corresponding function parameter.
with:
Recall that statEnv.funcType contains at most one function signature for any given (function name, arity) pair. The two following rules look up the function in the static environment and check that the type of each actual argument can be promoted to the type of the corresponding function parameter.
and remove:
Notice that the static context contains at most one function declaration for each function. This is possible since the treatment of overloaded operators is done through a set of specific static typing rules which do not require access to the environment. See [C.2 Mapping of Overloaded Internal Functions].
See Bug 3882
Change some wording in 4.1.5 [Function Calls] / Normalization.
29 Oct 2006: Proposed
30 Aug 2008: Accepted
30 Aug 2008: Issued
In 4.1.5 Function Calls / Normalization, replace:
Each argument expression in a function call is normalized to its corresponding Core expression by applying []FunctionArgument(Type) for each argument with the expected SequenceType for the argument inserted.
with:
Each argument expression in a function call is normalized to its corresponding Core expression by applying []FunctionArgument(Type) where Type is the corresponding parameter type.
In 4.1.5 Function Calls / Normalization / rule 1, remove:
| == |
| QName ( [Expr1]FunctionArgument(Type1), ..., [Exprn]FunctionArgument(Typen) ) |
In 4.1.5 Function Calls / Normalization, replace:
Note that this normalization rule depends on the function signatures, which is used to get the types of the function parameters (SequenceType1,...,SequenceTypen) . For user-defined functions, the function signature can be obtained from the XQuery prolog where the function is declared. For built-in functions, the signature is given in the [Functions and Operators] document. For overloaded built-in functions, several signatures may exists, however, because they all correspond to sequences of atomic values, they all result in the same normalization.
with:
See Bug 3879
Fix typos in 4 [Expressions].
29 Oct 2006: Proposed
30 Aug 2008: Accepted
30 Aug 2008: Issued
In 4 Expressions / Static Type Analysis, replace:
In general, static type errors are raised whenever there is no static typing rules which can compute the type of a given expression. This is the reason for the absence of a formal post-condition in this rules .
with:
In general, static type errors are raised whenever there are no static typing rules which can compute the type of a given expression. This is the reason for the absence of a formal conclusion in this rule.
See Bug 3876
Fix typo in 3.2.2 [Normalization mapping rules].
28 Oct 2006: Proposed
30 Aug 2008: Accepted
30 Aug 2008: Issued
In 3.2.2 Normalization mapping rules / Notation, replace:
for $i in (1, 2) return
for $j in (3, 4) return
element pair { ($i,$j) }
with:
for $i in (1, 2) return
for $j in (3, 4) return
element pair { ($i,$j) } {}
See Bug 3873
Fix typo in 2.5 [Functions and operators].
28 Oct 2006: Proposed
30 Aug 2008: Accepted
30 Aug 2008: Issued
In 2.5 Functions and operators, replace:
For instance, the
fn:unordered returns its input sequence in an
implementation-dependent order.
with:
For instance, the
fn:unordered function returns its input sequence in an
implementation-dependent order.
See Bug 3871
Fix typos in 2.4.4 [Top level definitions].
28 Oct 2006: Proposed
30 Aug 2008: Accepted
30 Aug 2008: Issued
In 2.4.4 Top level definitions, replace:
is represented as follow
define type SKU restrict xsd:string;
with:
is represented as follows
define type SKU restricts xsd:string;
See Bug 3871
In the production for Definitions, add a semicolon after each Definition. Adjust the rest of the spec accordingly.
28 Oct 2006: Proposed
30 Aug 2008: Accepted
30 Aug 2008: Issued
In 2.4.4 Top level definitions, replace:
| [40 (Formal)] | Definitions |
::= | (Definition Definitions)? |
with:
| [40 (Formal)] | Definitions |
::= | (Definition
Separator
Definitions)? |
(and similarly in A.2 Formal BNF)
and replace:
define type listOfMyIntType restricts xs:anySimpleType {
myInteger*
}
define type zipUnion restricts xs:anySimpleType {
USState | FrenchRegion
}
with:
define type listOfMyIntType restricts xs:anySimpleType {
myInteger*
};
define type zipUnion restricts xs:anySimpleType {
USState | FrenchRegion
};
and replace:
When the type derivation is omitted, the type derives by
restriction from xs:anyType. For instance:
define type Bib { element book* } =
define type Bib restricts xs:anyType { element book* }
with:
When the type derivation is omitted, the type derives by
restriction from xs:anyType. For instance, the following two type definitions are
equivalent:
define type Bib { element book* };
define type Bib restricts xs:anyType { element book* };
and replace:
define type Bib { } =
define type Bib { empty }
with:
define type Bib { };
define type Bib { empty };
In 2.4.5 Example of a complete Schema, replace:
define type NYCAddress extends USAddress {
element apt
}
define element apt of type fs:anon3
define type fs:anon3 restricts xsd:positiveInteger
define element usaddress substitutes for address of type USAddress
define element nycaddress substitutes for usaddress of type NYCAddress
with:
define type NYCAddress extends USAddress {
element apt
};
define element apt of type fs:anon3;
define type fs:anon3 restricts xsd:positiveInteger;
define element usaddress substitutes for address of type USAddress;
define element nycaddress substitutes for usaddress of type NYCAddress;
In 3.5.1 Predefined Schema Types, replace:
define type xs:string restricts xs:anyAtomicType
define type xs:boolean restricts xs:anyAtomicType
define type xs:decimal restricts xs:anyAtomicType
define type xs:float restricts xs:anyAtomicType
define type xs:double restricts xs:anyAtomicType
define type xs:duration restricts xs:anyAtomicType
define type xs:dateTime restricts xs:anyAtomicType
define type xs:time restricts xs:anyAtomicType
define type xs:date restricts xs:anyAtomicType
define type xs:gYearMonth restricts xs:anyAtomicType
define type xs:gYear restricts xs:anyAtomicType
define type xs:gMonthDay restricts xs:anyAtomicType
define type xs:gDay restricts xs:anyAtomicType
define type xs:gMonth restricts xs:anyAtomicType
define type xs:hexBinary restricts xs:anyAtomicType
define type xs:base64Binary restricts xs:anyAtomicType
define type xs:anyURI restricts xs:anyAtomicType
define type xs:QName restricts xs:anyAtomicType
define type xs:NOTATION restricts xs:anyAtomicType
with:
define type xs:string restricts xs:anyAtomicType;
define type xs:boolean restricts xs:anyAtomicType;
define type xs:decimal restricts xs:anyAtomicType;
define type xs:float restricts xs:anyAtomicType;
define type xs:double restricts xs:anyAtomicType;
define type xs:duration restricts xs:anyAtomicType;
define type xs:dateTime restricts xs:anyAtomicType;
define type xs:time restricts xs:anyAtomicType;
define type xs:date restricts xs:anyAtomicType;
define type xs:gYearMonth restricts xs:anyAtomicType;
define type xs:gYear restricts xs:anyAtomicType;
define type xs:gMonthDay restricts xs:anyAtomicType;
define type xs:gDay restricts xs:anyAtomicType;
define type xs:gMonth restricts xs:anyAtomicType;
define type xs:hexBinary restricts xs:anyAtomicType;
define type xs:base64Binary restricts xs:anyAtomicType;
define type xs:anyURI restricts xs:anyAtomicType;
define type xs:QName restricts xs:anyAtomicType;
define type xs:NOTATION restricts xs:anyAtomicType;
and replace:
define type xs:normalizedString restricts xs:string
define type xs:token restricts xs:normalizedString
define type xs:language restricts xs:token
define type xs:NMTOKEN restricts xs:token
define type xs:Name restricts xs:token
define type xs:NCName restricts xs:Name
define type xs:ID restricts xs:NCName
define type xs:IDREF restricts xs:NCName
define type xs:ENTITY restricts xs:NCName
define type xs:integer restricts xs:decimal
define type xs:nonPositiveInteger restricts xs:integer
define type xs:negativeInteger restricts xs:nonPositiveInteger
define type xs:long restricts xs:integer
define type xs:int restricts xs:long
define type xs:short restricts xs:int
define type xs:byte restricts xs:short
define type xs:nonNegativeInteger restricts xs:integer
define type xs:unsignedLong restricts xs:nonNegativeInteger
define type xs:unsignedInt restricts xs:unsignedLong
define type xs:unsignedShort restricts xs:unsignedInt
define type xs:unsignedByte restricts xs:unsignedShort
define type xs:positiveInteger restricts xs:nonNegativeInteger
with:
define type xs:normalizedString restricts xs:string;
define type xs:token restricts xs:normalizedString;
define type xs:language restricts xs:token;
define type xs:NMTOKEN restricts xs:token;
define type xs:Name restricts xs:token;
define type xs:NCName restricts xs:Name;
define type xs:ID restricts xs:NCName;
define type xs:IDREF restricts xs:NCName;
define type xs:ENTITY restricts xs:NCName;
define type xs:integer restricts xs:decimal;
define type xs:nonPositiveInteger restricts xs:integer;
define type xs:negativeInteger restricts xs:nonPositiveInteger;
define type xs:long restricts xs:integer;
define type xs:int restricts xs:long;
define type xs:short restricts xs:int;
define type xs:byte restricts xs:short;
define type xs:nonNegativeInteger restricts xs:integer;
define type xs:unsignedLong restricts xs:nonNegativeInteger;
define type xs:unsignedInt restricts xs:unsignedLong;
define type xs:unsignedShort restricts xs:unsignedInt;
define type xs:unsignedByte restricts xs:unsignedShort;
define type xs:positiveInteger restricts xs:nonNegativeInteger;
and replace:
define type xs:NMTOKENS restricts xs:anySimpleType { xs:NMTOKEN+ }
define type xs:IDREFS restricts xs:anySimpleType { xs:IDREF+ }
define type xs:ENTITIES restricts xs:anySimpleType { xs:ENTITY+ }
with:
define type xs:NMTOKENS restricts xs:anySimpleType { xs:NMTOKEN+ };
define type xs:IDREFS restricts xs:anySimpleType { xs:IDREF+ };
define type xs:ENTITIES restricts xs:anySimpleType { xs:ENTITY+ };
and replace:
define type xs:yearMonthDuration restricts xs:duration
define type xs:dayTimeDuration restricts xs:duration
with:
define type xs:yearMonthDuration restricts xs:duration;
define type xs:dayTimeDuration restricts xs:duration;
In 5.10 Schema Import / Static Context Processing / rule 5, replace:
with:
In 8.1.8 Builtin attributes, replace:
define attribute xsi:type of type xs:QName
define attribute xsi:nil of type xs:boolean
define attribute xsi:schemaLocation of type fs:anon
define type fs:anon1 { xs:anyURI* }
define attribute xsi:noNamespaceSchemaLocation of type xs:anyURI
with:
define attribute xsi:type of type xs:QName;
define attribute xsi:nil of type xs:boolean;
define attribute xsi:schemaLocation of type fs:anon;
define type fs:anon1 { xs:anyURI* };
define attribute xsi:noNamespaceSchemaLocation of type xs:anyURI;
See Bug 3868
Fix typos in 2.4.3 [Content models].
27 Oct 2006: Proposed
29 Aug 2008: Accepted
29 Aug 2008: Issued
In 2.4.3 Content models / Notation, replace:
The grammar for Type describe above is general enough to capture type infered for arbitrary expression, as well as to represent the content of an in [Schema Part 1].
with:
The grammar for Type described above is general enough to capture the type inferred for an arbitrary expression.
and replace:
| [42 (Formal)] | AttributeModel |
::= | AttributeType |
| [43 (Formal)] | ElementModel |
::= | ElementType |
with:
| [42 (Formal)] | AttributeModel |
::= | AttributeType |
| [43 (Formal)] | ElementModel |
::= | ElementType |
In A.2 Formal BNF / Non-Terminals, make the same grammar changes.
See Bug 3866
Fix typos in 2.4.1 [XML Schema and the [XPath/XQuery] Type System].
26 Oct 2006: Proposed
29 Aug 2008: Accepted
29 Aug 2008: Issued
In 2.4.1 XML Schema and the [XPath/XQuery] Type System, replace:
This document describe types in the [XPath/XQuery] types system, as well as the operations and properties over those types which are used to define the [XPath/XQuery] static typing feature. The two most important properties are whether a data instances matches a type, and whether a type is a subtype of another. Those properties are described in [8.3 Judgments for type matching]. This document does not describe all other possible properties over those types.
with:
This document describes types in the [XPath/XQuery] types system, as well as the operations and properties over those types which are used to define the [XPath/XQuery] static typing feature. The two most important properties are whether a data instance matches a type, and whether a type is a subtype of another. Those properties are described in [8.3 Judgments for type matching]. This document does not describe all other possible properties over those types.
and replace:
The mapping from XML Schema into the [XPath/XQuery] type system is given in [D Importing Schemas]. The rest of this section is organized as follows. [2.4.2 Item types] describes item types, [2.4.3 Content models] describes content models, and [2.4.4 Top level definitions] describe top-level type declarations.
with:
The mapping from XML Schema into the [XPath/XQuery] type system is given in [D Importing Schemas]. The rest of this section is organized as follows. [2.4.2 Item types] describes item types, [2.4.3 Content models] describes content models, and [2.4.4 Top level definitions] describes top-level type declarations.
See Bug 3865
Fix typo in 2.3.2 [Examples of values].
26 Oct 2006: Proposed
29 Aug 2008: Accepted
29 Aug 2008: Issued
In 2.3.2 Examples of values, replace:
element fact of type xs:untyped {
text { "The cat weighs " },
element weight of type xs:untyped {
attribute units of type xs:untypedAtomic {
"lbs" of type xs:untypedAtomic
}
text { "12" }
},
text { " pounds." }
}
with:
element fact of type xs:untyped {
text { "The cat weighs " },
element weight of type xs:untyped {
attribute units of type xs:untypedAtomic {
"lbs" of type xs:untypedAtomic
},
text { "12" }
},
text { " pounds." }
}
See Bug 3864
Fix typos in 2.3.1 [Formal values].
26 Oct 2006: Proposed
29 Aug 2008: Accepted
29 Aug 2008: Issued
In 2.3.1 Formal values / Notation, replace:
(The mapping is obvious, except that
"expanded-QName"
corresponds to xs:QName)
with:
(The mapping is obvious, except that
expanded-QName
corresponds to xs:QName.)
and replace:
For familiarity, these objects have been given the same appearance as StringLiterals from the XQuery and Core grammars; however, these are formal objects, with a distinct role in the FS.
with:
For familiarity, these objects have been given the same appearance as StringLiterals from the XQuery and Core grammars; however, these are formal objects, with a distinct role in the Formal Semantics.
See Bug 3861
Fix typo in 2.1.4 [Notations for inference rules].
25 Oct 2006: Proposed
29 Aug 2008: Accepted
29 Aug 2008: Issued
In 2.1.4 Notations for inference rules, replace:
This means that, in the context of a particular instantiation of a rule, one can talk about "the value of $VarName" instead of the value bound to the first (second, etc) occurrence of $VarName.
with:
This means that, in the context of a particular instantiation of a rule, one can talk about "the value of $VarName" instead of "the value bound to the first (second, etc) occurrence of $VarName".
See Bug 3268
Introduce Formal symbol OptDerivation.
9 May 2006: Proposed
29 Aug 2008: Accepted
29 Aug 2008: Issued
In 2.4.4 Top level definitions, replace:
| [34 (Formal)] | ComplexTypeDerivation |
::= | Derivation? OptMixed "{" Type? "}" |
with:
| [34 (Formal)] | ComplexTypeDerivation |
::= | OptDerivation
OptMixed "{" Type? "}" |
and insert:
| [95 (Formal)] | OptDerivation |
::= | Derivation? |
In A.2 Formal BNF, replace:
| [34] | ComplexTypeDerivation |
::= | Derivation? OptMixed "{" Type? "}" |
with:
| [34] | ComplexTypeDerivation |
::= | OptDerivation
OptMixed "{" Type? "}" |
and insert:
| [95] | OptDerivation |
::= | Derivation? |
In F.1.1 Type resolution / Semantics / rule 1, replace:
| statEnv |- Derivation? OptMixed { empty } resolves to TypeName { Type } |
|
|
| statEnv |- Derivation? OptMixed { } resolves to TypeName { Type } |
with:
| statEnv |- OptDerivation OptMixed { empty } resolves to TypeName { Type } |
|
|
| statEnv |- OptDerivation OptMixed { } resolves to TypeName { Type } |
In F.1.1 Type resolution / Semantics / rule 4 / premise 2, replace:
| statEnv.typeDefn(expanded-QName) = define type TypeName Derivation? BaseOptMixed { BaseType? } |
with:
| statEnv.typeDefn(expanded-QName) = define type TypeName OptDerivation BaseOptMixed { BaseType? } |
See Bug 3193
Fix typo in 5.14 [Variable Declaration].
4 May 2006: Proposed
29 Aug 2008: Accepted
29 Aug 2008: Issued
In 5.14 Variable Declaration / Static Context Processing / rule 2 / conclusion, replace:
with:
In 5.14 Variable Declaration / Static Context Processing / rule 3 / conclusion, replace:
with:
See Bug 1776
Adjust the formatting of a rule in 8.2.2.2 [Dynamic semantics of axes].
20 Jul 2005: Proposed
29 Aug 2008: Accepted
29 Aug 2008: Issued
In 8.2.2.2 Dynamic semantics of axes / Semantics / rule 11, replace:
with:
See Bug 5459
See Bug 5460
Fix the static typing for numeric and aggregate functions.
21 Jul 2008: Proposed
30 Jul 2008: Accepted
27 Aug 2008: Issued
In 7.2.3 The fn:abs, fn:ceiling, fn:floor, fn:round, and fn:round-half-to-even functions, replace the whole content of the section:
The static typing rules for the
fn:abs, fn:ceiling,
fn:floor, fn:round, and
fn:round-half-to-even functions promote their input
type to the (least) base primitive numeric type from which the
input type is derived. Note that the fact that the type should be
the least is not
expressed by the inference rule notation used here. Parameters of
type xs:untypedAtomic are always
promoted to xs:double. Instead of writing a separate judgment for each
function, we write one rule for the functions whose name is either
(FN-URI,"abs"),
(FN-URI,"ceiling"),
(FN-URI,"floor"),
(FN-URI,"round"), or
(FN-URI,"round-half-to-even")
functions.
|
||||||
|
|
||||||
| statEnv |- expanded-QName (Type) : Type1 · quantifier(Type) |
with:
Notation
The auxiliary judgment has base atomic type is used in the next subsection and also in [7.2.10 The fn:min, fn:max, fn:avg, and fn:sum functions].
To a first approximation, this
judgment holds when AtomicTypeName
1 is (or is derived from) primitive atomic type
AtomicTypeName
2. However, for the purpose of typing the functions
that use this judgment, there are three non-primitive atomic types
that are treated similarly to primitive types:
xs:integer (derived from xs:decimal), and
xs:yearMonthDuration
and xs:dayTimeDuration
(derived from xs:duration).
If AtomicTypeName
1 is (or is a subtype of) any primitive atomic type
other than xs:decimal or xs:duration,
then that type is its base atomic type.
|
||||
|
|
||||
|
Similarly for
xs:integer, xs:yearMonthDuration, and
xs:dayTimeDuration
.
|
|||
|
|
|||
|
For xs:decimal, we
exclude xs:integer and its subtypes:
|
|||
|
|
|||
|
And finally, for
xs:duration, we exclude xs:yearMonthDuration and
xs:dayTimeDuration ,
and their subtypes.
|
||||
|
|
||||
|
Note that, in the declarations for
the built-in functions fn:abs,
fn:ceiling, fn:floor,
fn:round, and fn:round-half-to-even, the
(first) parameter is declared with type "numeric?".
Thus, for a call to one of these functions, the normalization rules
of [4.1.5 Function Calls]
will have wrapped the argument in calls to fn:data()
and fs:convert-simple-operand()
(with a 'prototypical value' of type xs:double). Thus,
static analysis of the call is guaranteed that the argument type is
a subtype of xs:anyAtomicType*, with no
occurrences of xs:untypedAtomic.
In the static typing rule for these functions, we check that the argument type is numeric, extract its prime type (which must be a choice of atomic types), find the base atomic type for each, and then form the choice of those results.
|
||||||||
|
|
||||||||
|
The
fn:round-half-to-even function also has a
two-parameter version. Its static type-checking can be reduced to
that of the one-parameter version.
In 7.2.10 The fn:min, fn:max, fn:avg, and fn:sum functions / Static Type Analysis 1 / rule 1, replace:
with:
In 7.2.10 The fn:min, fn:max, fn:avg, and fn:sum functions / Static Type Analysis 2, replace the whole of the subsection:
Now we can define the static
typing rules for the aggregate functions. First, the input type is
converted to a prime type. Second, the type function convert_untypedAtomic is applied to the prime
type, yielding a new prime type, in which occurrences of xs:untypedAtomic are
converted to xs:double. Third, the judgment can be promoted
to is applied to the new prime type and target type. The
result type is combined with the aggregate quantifier of the input
type.
For a given aggregate function, instead of writing a separate judgment for each target type, we write one rule using a target type Type0.
For fn:min and
fn:max, the target type Type0
is either xs:string, xs:integer,
xs:decimal, xs:float,
xs:double, xs:date, xs:time,
xs:dateTime, xs:yearMonthDuration, or
xs:dayTimeDuration
.
|
||||
|
|
||||
statEnv |-
(FN-URI,"min")(Type) : empty
|
|
||||||||
|
|
||||||||
statEnv |-
(FN-URI,"min")(Type) : Type0
· aggregate_quantifier(quantifier(Type))
|
|
||||
|
|
||||
statEnv |-
(FN-URI,"max")(Type) : empty
|
|
||||||||
|
|
||||||||
statEnv |-
(FN-URI,"max")(Type) : Type0
· aggregate_quantifier(quantifier(Type))
|
For fn:avg, the
target type Type0
is either xs:decimal, xs:float,
xs:double, xs:yearMonthDuration, or
xs:dayTimeDuration
.
|
||||
|
|
||||
statEnv |-
(FN-URI,"avg")(Type) : empty
|
|
||||||||
|
|
||||||||
statEnv |-
(FN-URI,"avg")(Type) : Type0
· aggregate_quantifier(quantifier(Type))
|
For fn:sum, the
target type Type0
is either xs:integer, xs:decimal,
xs:float, xs:double, xs:yearMonthDuration, or
xs:dayTimeDuration .
The second argument in fn:sum is the value that should
be returned if the input sequence is empty. The result type is the
union of the target type and the type of the second argument. Note
that the rule checks that the type for the zero value is consistent
with the type of the input sequence.
|
||||
|
|
||||
statEnv |-
(FN-URI,"sum")(Type) : xs:integer |
|
||||||||||
|
|
||||||||||
statEnv |-
(FN-URI,"sum")(Type1,Type2)
: Type0
· aggregate_quantifier(quantifier(Type1))
|
with:
Now we can define the static
typing rules for the aggregate functions. Note that the
normalization rules of [4.1.5
Function Calls] will have wrapped each argument in calls to
fn:data() and fs:convert-simple-operand()
(with a 'prototypical value' of type xs:double). Thus,
static analysis of the call to an aggregate function is guaranteed
that any argument type is a subtype of xs:anyAtomicType*, with no
occurrences of xs:untypedAtomic.
First, we can quickly deal with
fn:avg. For the purposes of static type analysis,
fn:avg($arg) is equivalent to fs:div(
fn:sum($arg,()), fn:count($arg) ) Thus, we have the
rule:
|
|||
|
|
|||
|
For the remaining aggregate
functions (fn:min, fn:max, and
fn:sum), the general approach is as follows. First, we
check that the input type(s) are acceptable for the function. Then
we construct the (first) argument's prime type, a union of
AtomicTypeNames. For each of the latter, we find the 'base atomic
type'. The union of these base atomic types is the basis for the
result type, which may finally be adjusted for cardinality
(fn:min and fn:max) or for the effect of
the second argument (fn:sum). In addition, we provide
a rule for the special case when the (first) argument has type
'empty'.
For fn:min and
fn:max, the permitted input types are all those for
which ge(T,T) and le(T,T) are defined. An empty input sequence
yields an empty result.
|
|||
|
|
|||
|
|
|||||||||
|
|
|||||||||
|
For fn:sum, the
permitted input types for the first argument are all those for
which plus(T,T) is defined. If you pass an empty sequence as the
first argument, the function returns the value of the second
argument.
|
||||||||||
|
|
||||||||||
|
The second argument's contribution (if any) to the above result type is determined as follows. If the first argument could be the empty sequence, we add the type of the second argument to the result type. Otherwise, the type of the second argument is ignored.
In B Index of judgments, insert:
and insert:
See Bug 5747
Rework the rules for CastableExpr to avoid raising type errors (and fix various other problems).
5 Jul 2008: Proposed
15 Jul 2008: Accepted
25 Aug 2008: Issued
In 4.12.4 Castable / Normalization, replace:
| [Expr castable as AtomicType]Expr | ||
| == | ||
|
| [Expr castable as AtomicType?]Expr | ||
| == | ||
|
with:
In 4.12.4 Castable, before Dynamic Evaluation, insert:
Notation
The auxiliary judgment:
holds when Value can be atomized and cast to SingleType. Its definition depends on the cast value to type judgment.
In 4.12.4 Castable / Dynamic Evaluation, replace:
If casting succeeds,
then the
castable expression evaluates to true.
with:
If the value of the operand
expression can be cast to the given type, then the
castable expression evaluates to true.
In 4.12.4 Castable / Dynamic Evaluation / rule 1, replace:
|
||
|
|
||
|
with:
In 4.12.4 Castable / Dynamic Evaluation / rule 2, replace:
with:
In B Index of judgments, insert:
dynEnv |- Value can be cast to SingleType
See Bug 3771
Don't use the "interleave with empty text nodes" technique for attribute constructors.
18 Mar 2008: Proposed
18 Mar 2008: Accepted
24 Aug 2008: Issued
In 4.7.1.1 Attributes / Normalization, replace:
To apply []AttributeContent to zero or more
attribute-content units, we normalize each unit individually
and construct a sequence of the normalized results interleaved with empty text nodes. The
empty text nodes guarantee that the results of evaluating
consecutive attribute-content units can be distinguished.
Then we apply the function fs:item-sequence-to-untypedAtomic,
which applies the appropriate conversion rules to the normalized
attribute content:
with:
To apply []AttributeContent to zero or more
attribute-content units, we normalize each unit individually
and construct a sequence of the normalized results .
Then we apply the function fn:string-join, which will concatenate the values of the normalized units.
In 4.7.1.1 Attributes / Normalization / rule 5, replace:
| [ AttributeContentUnit1 ... AttributeContentUnitn ]AttributeContent |
| == |
fs:item-sequence-to-untypedAtomic
(([
AttributeContentUnit1
]AttributeContentUnit , text { "" }, ..., text {""}, [
AttributeContentUnitn]AttributeContentUnit) )
|
with:
| [ AttributeContentUnit1 ... AttributeContentUnitn ]AttributeContent |
| == |
| fn:string-join (([ AttributeContentUnit1 ]AttributeContentUnit , ..., [ AttributeContentUnitn]AttributeContentUnit) , '' ) |
In 4.7.1.1 Attributes / Normalization, replace:
We normalize an enclosed expression by normalizing each individual expression in its expression sequence and then constructing a sequence of the normalized values:
with:
We normalize an enclosed expression into
a call to the function fs:item-sequence-to-string,
which implements various rules for converting a sequence of atomic
values and nodes into a string.
In 4.7.1.1 Attributes / Normalization / rule 8, replace:
| [ { Expr1, ..., Exprn } ]AttributeContentUnit |
| == |
| ([ Expr1 ]Expr , ..., [ Exprn]Expr) |
with:
| [ { Expr } ]AttributeContentUnit |
| == |
fs:item-sequence-to-string((
[ Expr ]Expr )) |
In 4.7.3.2 Computed Attribute Constructors / Normalization, replace:
Computed attribute constructors are normalized by mapping their
name and content expression in a similar way as computed element
constructors. The normalization rule uses the fs:item-sequence-to-untypedAtomic
function.
with:
Computed attribute constructors are normalized by mapping their
name and content expression in a similar way as computed element
constructors. The normalization rule uses the
fs:item-sequence-to-string
function.
In 4.7.3.2 Computed Attribute Constructors / Normalization / rule 2, replace:
| [attribute QName { Expr }]Expr |
| == |
attribute
QName { fs:item-sequence-to-untypedAtomic
(([Expr]Expr)) }
|
with:
| [attribute QName { Expr }]Expr |
| == |
attribute
QName {
fs:item-sequence-to-string
(([Expr]Expr)) }
|
In 4.7.3.2 Computed Attribute Constructors / Normalization / rule 3, replace:
| [attribute { Expr1 } { Expr2 }]Expr |
| == |
attribute {
fn:data(([Expr1]Expr)) } {
fs:item-sequence-to-untypedAtomic
(([Expr2]Expr)) }
|
with:
| [attribute { Expr1 } { Expr2 }]Expr |
| == |
attribute {
fn:data(([Expr1]Expr)) } {
fs:item-sequence-to-string
(([Expr2]Expr)) }
|
In 4.7.3.2 Computed Attribute Constructors / Static Type Analysis / rule 1, replace:
|
|||
|
|
|||
statEnv |- attribute QName {
Expr } : attribute QName of type xs:untypedAtomic |
with:
In 4.7.3.2 Computed Attribute Constructors / Static Type Analysis / rule 2, replace:
with:
In 7.1.7 The fs:item-sequence-to-untypedAtomic function, replace every occurrence of:
with:
and in the function prototype, replace the return type:
xs:untypedAtomicwith:
xs:stringand replace
... converts a sequence of item values to a string
of type xs:untypedAtomic by applying ...
with:
... converts a sequence of item values to a string by applying ...
In C.1 Functions and Operators used in the Formal Semantics, add:
See Bug 5986
Fix cross-reference in 4.7.3.4.
24 Aug 2008: Proposed
24 Aug 2008: Accepted
24 Aug 2008: Issued
In 4.7.3.4 Text Node Constructors / Normalization, replace:
As formal specification of these conversion rules is not instructive, [7.1.7 The fs:item-sequence-to-untypedAtomic function] implements this conversion.
with:
As formal specification of these
conversion rules is not instructive,
the fs:item-sequence-to-untypedAtomic-text
function implements this conversion.
See Bug 3655
See Bug 3771
See Bug 4869
Don't use the "interleave with empty text nodes" technique for element constructors.
14 May 2008: Proposed
7 Jul 2008: Accepted
21 Aug 2008: Issued
In 4.7.1 Direct Element Constructors / Normalization, replace:
We normalize each unit individually and construct a sequence of
the normalized results interleaved with empty text nodes. The empty text nodes
guarantee that the results of evaluating consecutive
element-content units can be distinguished. Then we apply the
function fs:item-sequence-to-node-sequence.
Section 3.7.1
Direct Element ConstructorsXQ
specifies the rules for converting a sequence of atomic values and
nodes into a sequence of nodes before element construction. The
Formal Semantics function fs:item-sequence-to-node-sequence
implements these conversion rules.
with:
We normalize each unit individually and construct a sequence of the normalized results.
In 4.7.1 Direct Element Constructors / Normalization / rule 4, replace:
| [ElementContentUnit 1, ..., ElementContentUnit n]ElementContent |
| == |
fs:item-sequence-to-node-sequence((
[ ElementContentUnit
1 ]ElementContentUnit , text { "" }, ..., text { "" }, [ ElementContentUnit
n]ElementContentUnit )) |
with:
| [ElementContentUnit 1, ..., ElementContentUnit n]ElementContent |
| == |
| [ ElementContentUnit 1 ]ElementContentUnit , ..., [ ElementContentUnit n]ElementContentUnit |
In 4.7.1 Direct Element Constructors / Normalization, remove:
We must distinguish between the
results of consecutive element-content units, because the rule for
converting sequences of atomic values into strings applies to
sequences within distinct enclosed expressions. The empty text
nodes are eliminated during evaluation of fs:item-sequence-to-node-sequence
when consecutive text nodes are coalesced into a single text node.
The text node guarantees that a whitespace character will not be
inserted between atomic values computed by distinct enclosed
expressions. For example, here is an expression, its normalization,
and the resulting XML value:
<example>{ 1 }{ 2 }</example>
=
element example { fs:item-sequence-to-node-sequence ((1, text {""}, 2)) }
==>
<example>12</example>
In the absence of the empty text node, the expression would evaluate to the following incorrect value:
<example>{ 1 }{ 2 }</example>
(incorrect normalization) =
element example { fs:item-sequence-to-node-sequence ((1, 2)) }
(incorrect value) ==>
<example>1 2</example>
and replace:
An enclosed expression in element content is normalized by normalizing each individual expression in its expression sequence and then constructing a sequence of the normalized values:
with:
An enclosed expression in element content is normalized
into a call to the function fs:item-sequence-to-node-sequence,
which implements various rules for converting a sequence of atomic
values and nodes into a sequence of nodes before element
construction.
In 4.7.1 Direct Element Constructors / Normalization / rule 9, replace:
| [ { Expr1, ..., Exprn } ]ElementContentUnit |
| == |
| [ Expr1 ]Expr , ..., [ Exprn]Expr |
with:
| [ { Expr } ]ElementContentUnit |
| == |
fs:item-sequence-to-node-sequence((
[Expr]Expr )) |
In 4.7.3.1 Computed Element Constructors, before Dynamic Evaluation, insert:
Notation
The following auxiliary judgment is used in the dynamic semantics of node constructors.
This judgment is informally defined to hold when Value1 is obtained by applying the following modifications to Value0:
Adjacent text nodes in Value0 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 sequence.
In 4.7.3.1 Computed Element Constructors / Dynamic Evaluation, replace:
Second, the expression is evaluated, and the resulting value Value0 must match zero-or-more attributes followed by zero-or-more element, text, processing-instruction or comment nodes.
with:
Second, the expression is evaluated, and its value's text nodes are processed. The resulting sequence must match zero-or-more attributes followed by zero-or-more element, text, processing-instruction or comment nodes.
In 4.7.3.1 Computed Element Constructors / Dynamic Evaluation / rule 1, replace:
with:
In 4.7.3.1 Computed Element Constructors / Dynamic Evaluation / rule 2, replace:
|
|||||
|
|
|||||
statEnv; dynEnv |-
element QName { Expr } { LocalNamespaceDecls
} =>
element QName of type xs:anyType {
Value0 } { NamespaceBindings }
|
with:
|
||||||
|
|
||||||
statEnv; dynEnv |-
element QName { Expr } { LocalNamespaceDecls
} =>
element QName of type xs:anyType {
Value1 } { NamespaceBindings }
|
In 4.7.3.3 Document Node Constructors / Normalization, replace:
A document node constructor contains an expression, which must evaluate to a sequence of element, text, comment, or processing-instruction nodes. Section 3.7.3.3 Document Node ConstructorsXQ specifies the rules for converting a sequence of atomic values and nodes into a sequence of nodes before document construction. The built-in function [7.1.6 The fs:item-sequence-to-node-sequence-doc function] implements this conversion.
with:
A document node constructor contains an expression, which must
evaluate to a sequence of element, text, comment, or
processing-instruction nodes. Section
3.7.3.3 Document Node ConstructorsXQ
specifies the rules for converting a sequence of atomic values and
nodes into a sequence of nodes before document construction. The
built-in function
fs:item-sequence-to-node-sequence
implements most of this
conversion.
In 4.7.3.3 Document Node Constructors / Normalization / rule 1, replace:
| [document { Expr }]Expr |
| == |
document {
fs:item-sequence-to-node-sequence-doc
(([Expr]Expr)) }
|
with:
| [document { Expr }]Expr |
| == |
document {
fs:item-sequence-to-node-sequence
(([Expr]Expr)) }
|
In 4.7.3.3 Document Node Constructors / Static Type Analysis, replace:
The static typing rule does
not need to check that the type of the argument expression is a
sequence of element, text, processing-instruction, and comment
nodes, as it is already checked by the fs:item-sequence-to-node-sequence-doc
introduced during normalization. The type of the entire
expression is the most general document type, because
the document constructor erases all type
annotationXQ on its content
nodes.
with:
The type of the entire
expression is the most general document type, because
the document constructor erases all type
annotationXQ on its content
nodes.
In 4.7.3.3 Document Node Constructors / Static Type Analysis / rule 1, replace:
with:
In 4.7.3.3 Document Node Constructors / Dynamic Evaluation / rule 1, replace:
with:
In 4.7.3.3 Document Node Constructors / Dynamic Evaluation / rule 2, replace:
with:
In 7.1.5 The fs:item-sequence-to-node-sequence function, replace:
The fs:item-sequence-to-node-sequence
function converts a sequence of item values to nodes by applying
the normative rules numbered 1, 2, 3 after the
sentence "Processing of the computed element constructor proceeds
as follows:" in Section 3.7.3.1
Computed Element
ConstructorsXQ.
with:
The fs:item-sequence-to-node-sequence
function converts a sequence of item values to nodes by applying
the normative rules numbered 1e and 2 in
Section 3.7.1.3
ContentXQ (with the value bound to
$items playing the role of "the value of an enclosed
expression").
and replace:
If the input sequence contains any attribute nodes, they must precede any other items, with the exception that text nodes are allowed throughout. This exception results in looser type checking, but it is necessitated by the possible presence of empty text nodes introduced by normalization of direct element constructors (see [4.7.1 Direct Element Constructors]).
with:
If the input sequence contains any attribute nodes, they must precede any other items.
In 7.1.5 The fs:item-sequence-to-node-sequence function / Static Type Analysis, insert:
|
||
|
|
||
|
|
||
|
|
||
|
In 7.1.5 The fs:item-sequence-to-node-sequence function / Static Type Analysis / rule 1, replace:
with:
|
||
|
|
||
|
In 7.1 Formal Semantic Functions, remove:
item-sequence-to-node-sequence-doc
functionfs:item-sequence-to-node-sequence-doc(
$items as item()*) as node()*The fs:item-sequence-to-node-sequence-doc
function converts a sequence of item values to nodes by applying
the normative rules numbered 1, 2,
3 after the sentence "Processing of the document node
constructor then proceeds as follows:" in Section
3.7.3.3 Document Node
ConstructorsXQ.
In B Index of judgments, insert:
See Bug 5670
Call fn:boolean() in normalization of Where clause
29 Apr 2008: Proposed
13 May 2008: Accepted
19 Aug 2008: Issued
In 4.8.1 FLWOR expressions / Normalization / rule 3, replace:
with:
See Bug 5651
Provide (non-default) static typing for fn:not().
24 Apr 2008: Proposed
29 Apr 2008: Accepted
17 Aug 2008: Issued
In 7.2.4 The fn:boolean function, replace the title:
fn:boolean function
with:
fn:boolean and fn:not functions
In 7.2.4 The fn:boolean function / Static Type Analysis, after the first paragraph, add:
The fn:not function has an implicit call to
fn:boolean, and raises type errors for the same cases,
so its static typing is the same as fn:boolean.
In 7.2.4 The fn:boolean function / Static Type Analysis / rule 1, replace:
with:
|
|||
|
|
|||
statEnv
|- expanded-QName(Type) : xs:boolean |
See Bug 1757
Fix small errors in section 7.2.4 [The fn:boolean function].
6 Oct 2006: Proposed
17 Aug 2008: Accepted
17 Aug 2008: Issued
In 7.2.4 The fn:boolean function / Static Type Analysis, replace:
fn:boolean function
as described in the [Functions and Operators] document
takes
an empty sequence,
a sequence of one or more nodes,
or a singleton value of type
xs:boolean,
xs:string,
xs:untypedAtomic
or some numeric type.
All other values are illegal.
with:
fn:boolean function
as described in the [Functions and Operators] document
takes
an empty sequence,
a sequence whose first item is a node,
or a singleton value of type
xs:boolean,
xs:string,
xs:anyURI,xs:untypedAtomic
or some numeric type.
All other values are illegal.
The static typing of fn:boolean reflects these restrictions,
but further constrains "a sequence whose first item is a node"
to "a sequence of nodes".
In 7.2.4 The fn:boolean function / Static Type Analysis / rule 1, replace:
with:
See Bug 5601
For internal function fs:div, correct the result type in the Binary Operators table.
1 Apr 2008: Proposed
29 Apr 2008: Accepted
16 Aug 2008: Issued
In C.2 Mapping of Overloaded Internal Functions / Notation 2, in the 'Binary Operators' table, replace:
fs:div(A, B) |
xs:integer |
xs:integer |
op:numeric-divide(A, B) | xs:double |
with:
fs:div(A, B) |
xs:integer |
xs:integer |
op:numeric-divide(A, B) | xs:decimal |
See Bug 4841
Introduce fs:item-at() function.
13 Nov 2007: Proposed
28 Nov 2007: Accepted
16 Aug 2008: Issued
In 4.2.1 Steps / Normalization / rules 1+2+3+4, replace:
fn:subsequence(..., ..., 1)
with:
item-at(..., ...)
In 4.2.1 Steps / Normalization, in the paragraph after rule 4, replace:
fn:subsequence
to select a particular item.
The static typing rules for this function are defined in
[7.2.13 The fn:subsequence function].
with:
item-at
to select a particular item.
The static typing rules for this function are defined in
[7.1.14 The fs:item-at function].
In 4.3.2 Filter Expressions / Normalization, in the first paragraph, replace:
fn:subsequence
function
with:
item-at
function
In 4.3.2 Filter Expressions / Normalization / rules 1+2, replace:
fn:subsequence(..., ..., 1)
with:
item-at(..., ...)
In 7.1 Formal Semantics Functions, insert a new section:
item-at
functionfs:item-at($sourceSeq as item()*,
$loc as xs:double) as item()?The fs:item-at
function returns the item at a specified position in a
sequence.
If $loc is numeric-equal to the position of some
item in $sourceSeq, that item is returned. (This
implies that $sourceSeq is non-empty, and
$loc is numeric-equal to an integer between 1 and
n inclusive, where n is the number of
items in $sourceSeq.)
Otherwise, the empty sequence is returned.
The function is roughly equivalent to the following user-defined function.
declare function fs:item-at(
$sourceSeq as item()*,
$loc as xs:double) as item()?
{
if ($loc mod 1 eq 0) then
fn:subsequence($sourceSeq,$loc,1)
else
()
};
The static typing rules for invocations of fs:item-at depend on the
syntactic form of the second argument. If it is the IntegerLiteral
1, then we can be relatively precise about the resulting type.
|
||||
|
|
||||
|
Otherwise, the following less precise rule is used.
|
|||
|
|
|||
|
(Since invocations of fs:item-at arise only as
the result of particular normalization rules, Expr2 in the
above rule must be either $fs:last,
$fs:position, or a NumericLiteral. Thus, there is no
need to check its type.)
In 7.2.13 The fn:subsequence function, replace the whole of the section content:
Introduction
The fn:subsequence function has special static
typing rules when its second argument is the numeric literal value
1 or the built-in variable $fs:last.
These rules provide better typing for path expressions such as
Expr[1] and Expr[fn:last()].
The static typing rules for fn:subsequence depends
on the syntactic form of their input expression. As a result, the
corresponding static typing rules must be written directly over the
input expression, unlike the other functions in this section.
If the type of the input expression has exactly one or
one-or-more items, then the type inferred for
fn:subsequence is the prime type of the input
type.
|
|||
|
|
|||
|
If the type of the input expression has zero or more items,
fn:subsequence is applied on a numeric literal,
$fs:position,
or $fs:last,
then the static type is zero-or-one of the prime type of the input
type. Those static typing rules are intended to support more
precise typing for the cases where fn:subsequence is
the result of normalizing an XPath predicate of the form
Expr[NumericLiteral] of Expr[last()],
see [4.2.1 Steps].
|
|||
|
|
|||
|
The same rule applies when the last item in the input sequence is selected.
|
|||
|
|
|||
|
The same rule applies when an item is selected based on its position in the input sequence.
|
|||
|
|
|||
|
The last rule applies to all other applications of the
fn:subsequence function.
with:
The static type of a call to fn:subsequence is
computed using prime() and
quantifier(), which
are defined in [8.4 Judgments for FLWOR
and other expressions on sequences].
In C.1 Functions and Operators used in the Formal Semantics, remove:
See Bug 3269
ElementNameOrWildcard and AttributeNameOrWildcard do not derive empty.
9 May 2006: Proposed
15 Jul 2006: Accepted
15 Jul 2008: Issued
Wherever a judgment assumes that ElementNameOrWildcard or AttributeNameOrWildcard derives the empty string, change it to "*". For example, where "element" or "element of type TypeName" appears as an ElementType, insert a "*" after "element". Similarly, where "attribute" or "attribute of type TypeName" appears as an AttributeType, insert a "*" after "attribute".
The affected rules are as follows:
See Bug 3946
Make the static typing of processing-instructions consistent with their dynamic typing.
8 May 2007: Proposed
28 Nov 2007: Accepted
14 Jul 2008: Issued
In 2.4.2 Item types (and identically in A.2 Formal BNF), replace:
| [27 (Formal)] | ElementContentType |
::= | ElementType |
with:
| [27 (Formal)] | ElementContentType |
::= | ElementType |
and insert:
| [93 (Formal)] | ProcessingInstructionType |
::= | "processing-instruction" PITargetOrWildcard |
| [94 (Formal)] | PITargetOrWildcard |
::= | NCName | "*" |
In 3.5.4 SequenceType Matching / Normalization, replace:
The [XPath/XQuery] type system does not model the target of a processing-instruction, which is treated as a dynamic property. Therefore a "processing-instruction" SequenceType with a string or NCName parameter is normalized into an optional processing-instruction type.
| [processing-instruction(StringLiteral) ]sequencetype |
| == |
| processing-instruction? |
| [processing-instruction(NCName)]sequencetype |
| == |
| processing-instruction? |
with:
| [processing-instruction(NCName)]sequencetype |
| == |
| processing-instruction NCName |
For backward compatibility with XPath 1.0, the PITarget of a PITest may also be expressed as a string literal. The following rule handles that case.
|
|||
|
|
|||
| [processing-instruction(StringLiteral) ]sequencetype = processing-instruction NCName |
In 4.7.3.5 Computed Processing Instruction Constructors / Static Type Analysis / rule 1, replace:
with:
In 8.2.3.1.2 Kind Tests / Processing instruction, comment, and text kind tests, replace:
|
|
statEnv |- test
processing-instruction() with PrincipalNodeKind
of
processing-instruction : processing-instruction
|
A processing-instruction node test with a string literal or NCName matches a processing instruction whose target has the given name. Since target matching cannot be checked statically, the static type of the node test is zero-or-one processing instruction.
with:
| [PITest]sequencetype = processing-instruction * |
|
|
| statEnv |- test PITest with PrincipalNodeKind of ProcessingInstructionType : ProcessingInstructionType |
A processing-instruction node test with a string literal or NCName matches a processing instruction whose target has the given name.
In 8.3.1 Matches / Semantics, replace:
A processing-instruction node matches processing-instruction.
with:
A processing-instruction node matches the general processing-instruction type, and also the particular processing-instruction type that shares its PITarget.
Anywhere else that "processing-instruction" is used as a Type, replace:
with:
More specifically, that's in:
See Bug 3818
Avoid loss of type information in normalized path expressions.
20 Feb 2007: Proposed
3 May 2007: Accepted
8 Jul 2008: Issued
In 4.2 Path Expressions / Normalization / rule 5, replace:
with:
In 7.1 Formal Semantics Functions, add the section:
node-sequence
functionfs:node-sequence($nodes as node()*) as node()*If the input is a (possibly empty) sequence of nodes, fs:node-sequence
simply returns that sequence. Otherwise, it raises a type
error.
The static type of a call to fs:node-sequence is
that of its argument, as long as that type is a subtype of
node()*.
| statEnv |- Type <: [node()*]sequencetype |
|
|
statEnv |- (FS-URI,"node-sequence")(
Type) : Type |
See Bug 4766
Correct errors in examples in section 2.4.4.
26 Jun 2007: Proposed
26 Jun 2007: Accepted
4 Oct 2007: Issued
In 2.4.4 Top level definitions / Example 1, replace:
define type UKAddress extends ipo:Address {
attribute exportCode of type ipo:UKPostcode
element postcode of type positiveInteger
};
with:
define type UKAddress extends ipo:Address {
attribute exportCode of type positiveInteger,
element postcode of type ipo:UKPostcode
};
In 2.4.4 Top level definitions / Example 6, replace:
A type declaration with one element name of type
xs:string follows by one or more elements street of
type xs:string.
define type Address {
element name of type xs:string,
element street of type xs:string*
}
with:
A type declaration with one element name of type
xs:string followed by one or more elements
street of type xs:string.
define type Address {
element name of type xs:string,
element street of type xs:string+
}
In 2.4.4 Top level definitions / Example 7, replace:
define type USAddress extends Address {
element zip name of type xs:integer
}
with:
define type USAddress extends Address {
element zip of type xs:integer
}
See Bug 4578
Correct a normalization error in section 4.3.2 Filter Expressions.
24 May 2007: Proposed
30 May 2007: Accepted
4 Oct 2007: Issued
In 4.3.2 Filter Expressions / Normalization / rule 2, replace:
with:
let $fs:sequence :=
[PrimaryExpr
PredicateList]Expr
return
|
let $fs:last
:= fn:count($fs:sequence)
return
|
fn:subsequence($fs:sequence,
$fs:last,1)
|
See Bug 4242
See Bug 4261
See Bug 4512
See Bug 4581
See Bug 5129
See Bug 3269
Correct various errors in section 8.2.3.1.1.
28 Apr 2007: Proposed
3 May 2007: Accepted
3 Oct 2007: Issued
The following 6 changes resolve bugs 4242, 4261(a), and 4581 (by adding a "?" at the end of the result types), and some of 3269 (by fixing the input types in four of the rules).
In rule 2 / conclusion, replace:
statEnv |- test QName2 with element of element * OptTypeSpecifier : element
QName2 OptTypeSpecifier
|
with:
statEnv |- test QName2 with element of element * OptTypeSpecifier : element
QName2 OptTypeSpecifier
?
|
In rule 5 / conclusion, replace:
statEnv |- test
*:LocalPart2
with element
of element *
OptTypeSpecifier
: element
*:LocalPart2
OptTypeSpecifier
|
with:
statEnv |- test
*:LocalPart2
with element
of element *
OptTypeSpecifier
: element
*
OptTypeSpecifier
?
|
In rule 7 / conclusion, replace:
statEnv |- test Prefix2:* with element of element * OptTypeSpecifier : element
Prefix2:*
OptTypeSpecifier
|
with:
statEnv |- test Prefix2:* with element of element * OptTypeSpecifier : element
*
OptTypeSpecifier
?
|
In rule 10 / conclusion, replace:
statEnv |- test QName2 with attribute of attribute * OptTypeReference : attribute
QName2 OptTypeReference
|
with:
statEnv |- test QName2 with attribute of attribute * OptTypeReference : attribute
QName2 OptTypeReference
?
|
In rule 13 / conclusion, replace:
statEnv |- test
*:LocalPart2
with attribute
of attribute *
OptTypeReference
: attribute
*:LocalPart2
OptTypeReference
|
with:
statEnv |- test
*:LocalPart2
with attribute
of attribute *
OptTypeReference
: attribute
*
OptTypeReference
?
|
In rule 15 / conclusion, replace:
statEnv |- test Prefix2:* with attribute of attribute * OptTypeReference : attribute
Prefix2:*
OptTypeReference
|
with:
statEnv |- test Prefix2:* with attribute of attribute * OptTypeReference : attribute
*
OptTypeReference
?
|
The following 3 changes resolve bugs 4261(b), 4261(c), and 5129, respectively.
In rule 4, delete premises 2 and 3:
| statEnv.namespace(Prefix1) = (NamespaceKind,AnyURI) |
fn:namespace-uri-from-QName(expanded-QName1) = AnyURI |
In rule 6 / premise 2, replace:
| statEnv.namespace(Prefix 1 ) = (NamespaceKind,AnyURI) |
with:
| statEnv.namespace(Prefix 2 ) = (NamespaceKind,AnyURI) |
In rule 14 / premise 2, replace:
| statEnv |- QName1 of elem/type expands to expanded-QName1 |
with:
| statEnv |- QName1 of attr expands to expanded-QName1 |
The following 7 changes resolve bug 4261(d).
Between rules 1 and 2, insert this rule:
|
||||
|
|
||||
|
Between rules 4 and 5, insert this rule:
|
||||
|
|
||||
|
Between rules 6 and 7, insert this rule:
|
|||||
|
|
|||||
|
Between rules 9 and 10, insert this rule:
|
||||
|
|
||||
|
Between rules 12 and 13, insert this rule:
|
||||
|
|
||||
|
Between rules 14 and 15, insert this rule:
|
|||||
|
|
|||||
|
Delete rule 17:
Lastly, if none of the above rules holds, then the type of the input expression is empty.
|
|||||||||
|
|
|||||||||
| statEnv |- test NameTest with element of element ElementNameOrWildcard 2 TypeSpecifier2 : empty |
The following 2 changes resolve bug 4512(a).
In rule 8 / conclusion, replace:
statEnv |- test * with element of
element QName OptTypeSpecifier
:
element QName OptTypeSpecifier
|
with:
statEnv |- test * with element of
ElementType
:
ElementType
|
In rule 16 / conclusion, replace:
statEnv |- test * with attribute of
attribute QName OptTypeReference
:
attribute QName OptTypeReference
|
with:
statEnv |- test * with attribute of
AttributeType
:
AttributeType
|
The following 2 changes resolve bug 4512(b).
Between rules 8 and 9, insert this rule:
Between rule 16 and 17, insert this rule:
The next 2 changes resolve some more of bug 3269.
Delete rule 3:
|
|
| statEnv |- test QName2 with element of element OptTypeSpecifier : element QName2 OptTypeSpecifier |
Delete rule 11:
|
|
| statEnv |- test QName2 with attribute of attribute OptTypeReference : attribute QName2 OptTypeReference |
See Bug 4371
Update the "Processing Model" diagram.
6 Mar 2007: Proposed
6 Mar 2007: Accepted
2 Oct 2007: Issued
In 3.2.1 Processing model, in the diagram, add a box labelled "Modules", and an arrow labelled "(SQ3)" pointing from the "Modules" box to the "Static context" box.
See Bug 3847
For internal function fs:idiv, correct the operand types and supporting op: function given in the Binary Operators table.
18 Oct 2006: Proposed
14 Feb 2007: Accepted
2 Oct 2007: Issued
In C.2 Mapping of Overloaded Internal Functions / Notation 2, in the 'Binary Operators' table, replace:
fs:idiv(A, B) |
xs:integer |
xs:integer |
op:integer-div(A, B) | xs:integer |
with:
fs:idiv(A, B) |
xs:integer |
xs:integer |
op:numeric-integer-divide(A, B) | xs:integer |
fs:idiv(A, B) |
xs:decimal |
xs:decimal |
op:numeric-integer-divide(A, B) | xs:integer |
fs:idiv(A, B) |
xs:float |
xs:float |
op:numeric-integer-divide(A, B) | xs:integer |
fs:idiv(A, B) |
xs:double |
xs:double |
op:numeric-integer-divide(A, B) | xs:integer |
See Bug 1783
Fix some small errors in section 8.4.
6 Oct 2006: Proposed
16 Jan 2007: Accepted
2 Oct 2007: Issued
In 8.4 Judgments for FLWOR and other expressions on sequences, replace:
[Definition: A Prime types is a choice of item types].
with:
[Definition: A prime type is a choice of item types.]
Superseded by Erratum FS.E033
See Bug 1756
Fix small errors in section 7.2.3.
8 Sep 2006: Proposed
16 Jan 2007: Accepted
9 Aug 2007: Proposed
9 Aug 2007: Accepted
2 Oct 2007: Issued
In 7.2.3 The fn:abs, fn:ceiling, fn:floor, fn:round, and fn:round-half-to-even functions / Static Type Analysis / para 1, replace:
Note that the fact that the type should be the least is cannot expressed by the inference rule notation used here.
with:
Note that the fact that the type should be the least is not expressed by the inference rule notation used here.
and delete:
Instead of writing a separate
judgment for each function, we write one rule for the functions
whose name is either (FN-URI,"abs"),
(FN-URI,"ceiling"),
(FN-URI,"floor"),
(FN-URI,"round"), or
(FN-URI,"round-half-to-even")
functions.
In 7.2.3 The fn:abs, fn:ceiling, fn:floor, fn:round, and fn:round-half-to-even functions / Static Type Analysis / rule 1 / premise 5, replace:
FN-URI,"ceiling"),
(FN-URI,"floor"),
(FN-URI,"round"),
(FN-URI,"round-half-to-even") }
with:
FN-URI,"abs"),
(FN-URI,"ceiling"),
(FN-URI,"floor"),
(FN-URI,"round"),
(FN-URI,"round-half-to-even") }
See Bug 1754
Fix small errors in sections 7.2.1 and 7.2.2.
5 Oct 2006: Proposed
16 Jan 2007: Accepted
2 Oct 2007: Issued
In 7.2.1 The fn:last context function / Dynamic Evaluation / rule 1 / conclusion, replace:
with:
In 7.2.2 The fn:position context function / Dynamic Evaluation / rule 1 / conclusion, replace:
with:
See Bug 3771
Static Type Analysis must allow for empty text nodes introduced during normalization of direct element constructors.
10 Oct 2006: Proposed
19 Oct 2006: Accepted
2 Oct 2007: Issued
In 4.7.3.1 Computed Element Constructors / Static Type Analysis, replace:
The content expression must return a sequence of nodes with all the attribute nodes before any element, processing-instructions or comment nodes. Note that the type allows text nodes interleaved with attribute nodes in the beginning. Although this results in a looser type checking, this accounts for the possible presence of empty text nodes resulting from normalization of direct element constructors (See [4.7.1 Direct Element Constructors]).
with:
The content expression must return a sequence of nodes with attribute nodes at the beginning.
and in each of the four rules, in the last premise, replace:
(attribute*, (element | comment | processing-instruction)*) & text*
with:
attribute *, (element | text | comment | processing-instruction) *
In 7.1.5 The fs:item-sequence-to-node-sequence function / Static Type Analysis, insert:
If the input sequence contains any attribute nodes, they must precede any other items, with the exception that text nodes are allowed throughout. This exception results in looser type checking, but it is necessitated by the possible presence of empty text nodes introduced by normalization of direct element constructors (see [4.7.1 Direct Element Constructors]).
and in the subsequent rule, replace:
attribute*,
(element|document|text|processing-instruction|comment|xs:string|
xs:float| ...|xs:NOTATION)*
with:
( attribute*,
(element|document|processing-instruction|comment|xs:string|
xs:float|...|xs:NOTATION)* ) & text*
See Bug 3758
See Bug 3760
Correct/simplify/complete the Normalization rules defining []ElementContent and []AttributeContent, and simplify the corresponding Dynamic Evaluation rules.
10 Oct 2006: Proposed
19 Oct 2006: Accepted
1 Oct 2007: Issued
In 4.7.1 Direct Element Constructors / Normalization, delete:
We distinguish between direct element constructors that contain only one element-content unit and those that contain more than one element-content unit.
and delete rule 3:
and after the former rule 4 / now rule 3, insert:
(Note that this rule should be understood to cover the degenerate cases of n=0 and n=1, where the element constructor's content consists of zero or one element-content units.)
In 4.7.1.1 Attributes / Normalization, replace:
As with literal XML elements, we need to distinguish between direct attribute constructors that contain one attribute-content unit and those that contain multiple attribute-content units, because the rule for converting sequences of atomic values into strings is applied to sequences within distinct enclosed expressions. If the direct attribute constructor contains exactly one attribute-content unit, we simply normalize that unit by applying the normalization rule for attribute content units:
| [ AttributeContentUnit1 ]AttributeContent |
| == |
| [AttributeContentUnit1]AttributeContentUnit |
If the direct attribute constructor contains more than one attribute-content unit, we normalize each unit individually and ...
with:
To apply []AttributeContent to zero or more attribute-content units, we normalize each unit individually and ...
and after the former rule 5 / now rule 4, insert:
(Note that this rule should be understood to cover the degenerate cases of n=0 and n=1, where the attribute constructor's content consists of zero or one attribute-content units.)
In 4.7.3.2 Computed Attribute Constructors / Dynamic Evaluation, replace:
Second, the function
fs:item-sequence-to-untypedAtomic
is applied to the content expression and this function call is
evaluated in the dynamic environment. Recall from [4.7.3.2 Computed Attribute
Constructors] that during normalization, we do not convert
the content of direct attribute constructors that contain one
attribute-content unit. This guarantees that useful type
information is preserved for static analysis. Since the conversion
function fs:item-sequence-to-untypedAtomic
was not applied to all attribute constructors during normalization,
we have to apply it at evaluation time. (As before, it is possible
to elide the application of fs:item-sequence-to-untypedAtomic
injected during normalization and the application injected during
evaluation.)
with:
Second, the content expression is evaluated in the dynamic environment.
and in rule 1 / premise 1, replace:
dynEnv |- fs:item-sequence-to-untypedAtomic((
Expr)) =>
AtomicValue |
with:
| dynEnv |- Expr => AtomicValue |
and in rule 2 / premise 4, replace:
dynEnv |- fs:item-sequence-to-untypedAtomic((
Expr2)) => AtomicValue2 |
with:
| dynEnv |- Expr2 => AtomicValue2 |
See Bug 3670
Clean up due to the removal of op:anyURI-equal from the F+O spec.
26 Sep 2006: Proposed
26 Sep 2006: Accepted
30 Sep 2007: Issued
In C.2 Mapping of Overloaded Internal Functions / Notation 2, in the 'Binary Operators' table, replace:
fs:eq(A, B) |
xs:anyURI |
xs:anyURI |
op:anyURI-equal(A, B) | xs:boolean |
| ... | ||||
fs:ne(A, B) |
xs:anyURI |
xs:anyURI |
fn:not(op:anyURI-equal(A, B)) |
xs:boolean |
with:
fs:eq(A, B) |
xs:anyURI |
xs:anyURI |
op:numeric-equal(fn:compare(A, B), 0) | xs:boolean |
| ... | ||||
fs:ne(A, B) |
xs:anyURI |
xs:anyURI |
fn:not(op:numeric-equal(fn:compare(A, B),
0)) |
xs:boolean |
In 8.5.1 Type Promotion / Semantics, insert:
xs:anyURI can be promoted to
xs:string:
|
|
||
|
See Bug 3142
Fix some errors in the productions for FunctionSig and TypeList.
21 Apr 2006: Proposed
24 Apr 2006: Accepted
29 Sep 2007: Issued
In 3.1.1 Static Context / Notation and A.2 Formal BNF / Non-Terminals, replace:
| [85 (Formal)] | FunctionSig |
::= | "declare" "function" expanded-QName "(" TypeList? ")" "as" SequenceType |
| [86 (Formal)] | TypeList |
::= | SequenceType (","
Type)* |
with:
| [85 (Formal)] | FunctionSig |
::= | "declare" "function" expanded-QName "(" TypeList? ")" "as" Type |
| [86 (Formal)] | TypeList |
::= | Type ("," Type)* |
See Bug 1680
Fix a bug in the normalization of function calls.
17 Jul 2005: Proposed
24 Apr 2006: Accepted
29 Sep 2007: Issued
In 4.1.5 Function Calls / Normalization / rule 1 / premise 2, replace:
| statEnv.typeDefn(expanded-QName) = define type QName2 AtomicTypeDerivation |
with:
In 4.12.5 Constructor Functions, add the subsection:
Notation
Calls to constructor functions are normalized differently from other function calls, so we introduce an auxiliary judgment to detect whether the function being called is a constructor function.
This judgment holds when the expanded function name maps to an atomic type in the in-scope schema types.
|
||
|
|
||
| statEnv |- expanded-QName denotes a constructor function |
In 4.12.5 Constructor Functions / Normalization / para 1, replace:
... and checks whether than name stands for an atomic type in the static context.
with:
... and confirm that it denotes a constructor function in the static context.
In 4.12.5 Constructor Functions / Normalization / rule 1 / premise 2, replace:
| statEnv.typeDefn(expanded-QName) = define type QName2 AtomicTypeDerivation |
with:
In B Index of judgments / Auxiliary judgments, add:
See Bug 1694
Fix miscellaneous small errors in section 5.
17 Jul 2005: Proposed
18 Apr 2006: Accepted
29 Sep 2007: Issued
In 5 Modules and Prologs / Static Context Processing / rules 2+3 / premise 2, replace:
| [PrologDecl]PrologDecl == PrologDecl1 |
with:
| [PrologDecl]PrologDecl = PrologDecl1 |
In 5 Modules and Prologs / Static Type Analysis / rule 1 / premise 2, replace:
with:
In 5 Modules and Prologs / Dynamic Evaluation / rule 1, replace:
| dynEnvDefault |- PrologDeclList =>dyn dynEnv |
| statEnvDefault |- PrologDeclList =>stat statEnv1 |
| statEnv |- [QueryBody]Expr == Expr2 |
| dynEnv |- Expr2 => Value |
with:
See Bug 3875
See Bug 3184
See Bug 3885
See Bug 3194
See Bug 1715
Fix problems involving the domains of statEnv.funcType and dynEnv.funcDefn:
(expanded-QName, arity),
some inference rules neglect the arity.
expanded-QName(Type1, ..., Typen),
this leads to misunderstandings and mistakes;
dynEnv.funcDefn should have the same domain as statEnv.funcType.
3 May 2006: Proposed
20 Sep 2007: Accepted
20 Sep 2007: Issued
In 3.1.1 Static Context / Notation, insert:
In the static (and dynamic) context, each function is uniquely identified by its expanded QName and its arity (number of parameters). We introduce the auxilliary symbol FunctionKey to encapsulate this combination.
| [92 (Formal)] | FunctionKey |
::= | expanded-QName "," Arity |
(Arity is understood to be a non-negative integer.)
Also, add the FunctionKey production to A.2 Formal BNF / Non-Terminals.
In 3.1.1 Static Context / Notation / statEnv.funcType, replace:
... this environment component maps an expanded QName and an arity to a function signature FunctionSig.
with:
... this environment component maps a FunctionKey (an expanded QName and arity) to a function signature FunctionSig.
In 3.1.2 Dynamic Context / dynEnv.funcDefn, replace:
with:
In 4.1.5 Function Calls / Dynamic Evaluation / rule 1 / premise 2, replace:
| statEnv.funcType(expanded-QName) = FunctionSig |
with:
| statEnv.funcType(expanded-QName,0) = FunctionSig |
In 4.1.5 Function Calls / Dynamic Evaluation / rule 2 / premise 5, replace:
| statEnv.funcType(expanded-QName) = FunctionSig |
with:
| statEnv.funcType(expanded-QName,n) = FunctionSig |
In 4.1.5 Function Calls / Dynamic Evaluation / rule 3 / premise 1, replace:
| dynEnv.funcDefn(expanded-QName() = (Expr) |
with:
| dynEnv.funcDefn(expanded-QName,0) = (Expr) |
In 4.1.5 Function Calls / Dynamic Evaluation / rule 4 / premise 1, replace:
| dynEnv.funcDefn(expanded-QName(Type1, ..., Typen)) = (Expr, Variable1, ... , Variablen) |
with:
| dynEnv.funcDefn(expanded-QName,n) = (Expr, Variable1, ... , Variablen) |
In 4.1.5 Function Calls / Dynamic Evaluation / rule 5 / premises 1+4+6, replace:
dynEnv.funcDefn(expanded-QName()) =
#IMPORTED(AnyURI)
|
| ... |
| statEnv.funcType1(expanded-QName) = FunctionSig' |
| ... |
| dynEnv1.funcDefn(expanded-QName() = (Expr) |
with:
dynEnv.funcDefn(expanded-QName,0) =
#IMPORTED(AnyURI)
|
| ... |
| statEnv1.funcType(expanded-QName,0) = FunctionSig' |
| ... |
| dynEnv1.funcDefn(expanded-QName,0) = (Expr) |
(Note that this also fixes premise 4's "statEnv.funcType1" typo in passing.)
In 4.1.5 Function Calls / Dynamic Evaluation / rule 6 / premises 1+4+9, replace:
dynEnv.funcDefn(expanded-QName(Type1,
..., Typen)) = #IMPORTED(AnyURI)
|
| ... |
| statEnv.funcType1(expanded-QName) = FunctionSig' |
| ... |
| dynEnv1.funcDefn(expanded-QName(Type1', ..., Typen')) = (Expr, Variable1, ... , Variablen) |
with:
dynEnv.funcDefn(expanded-QName,n) =
#IMPORTED(AnyURI)
|
| ... |
| statEnv1.funcType(expanded-QName,n) = FunctionSig' |
| ... |
| dynEnv1.funcDefn(expanded-QName,n) = (Expr, Variable1, ... , Variablen) |
(Note that this also fixes premise 4's "statEnv.funcType1" typo in passing.)
In 4.1.5 Function Calls / Dynamic Evaluation / rule 7 / premise 1, replace:
dynEnv.funcDefn(expanded-QName()) =
#BUILT-IN |
with:
dynEnv.funcDefn(expanded-QName,0) =
#BUILT-IN |
In 4.1.5 Function Calls / Dynamic Evaluation / rule 8 / premise 1, replace:
dynEnv.funcDefn(expanded-QName(Type1,
..., Typen)) = #BUILT-IN |
with:
dynEnv.funcDefn(expanded-QName,n) =
#BUILT-IN |
In 4.1.5 Function Calls / Dynamic Evaluation / rule 9 / premise 1, replace:
dynEnv.funcDefn(expanded-QName()) =
#EXTERNAL |
with:
dynEnv.funcDefn(expanded-QName,0) =
#EXTERNAL |
In 4.1.5 Function Calls / Dynamic Evaluation / rule 10 / premise 1, replace:
dynEnv.funcDefn(expanded-QName(Type1,
..., Typen)) = #EXTERNAL |
with:
dynEnv.funcDefn(expanded-QName,n) =
#EXTERNAL |
In 5 Modules and Prologs / Notation 3 / rule 4 / premise 8, replace:
| statEnv1 = statEnv + funcType(expanded-QName => FunctionSig) |
with:
| statEnv1 = statEnv + funcType(expanded-QName,n => FunctionSig) |
In 5.11 Module Import / Notation 1 / para 3, replace:
The function
fs:local-functions(
statEnv, AnyURI)
returns all the function signatures in
statEnv.funcType
such that ...
with:
The function
fs:local-functions(
statEnv, AnyURI)
returns all the (FunctionKey, FunctionSig) pairs in
statEnv.funcType
such that ...
In 5.11 Module Import / Notation 2 / rule 1 / premises 3+4, replace:
fs:local-functions(statEnv2,
AnyURI) = (expanded-QName1,FunctionSig1) ... (expanded-QNamen,FunctionSign)
|
| statEnv4 = statEnv3 + funcType(expanded-QName1 => FunctionSig1; ... ;expanded-QNamen => FunctionSign) |
with:
fs:local-functions(statEnv2,
AnyURI) = (FunctionKey1,FunctionSig1) ... (FunctionKeyn,FunctionSign)
|
| statEnv4 = statEnv3 + funcType( FunctionKey1 => FunctionSig1; ... ; FunctionKeyn => FunctionSign ) |
In 5.11 Module Import / Notation 3 / rule 4, replace:
|
|||
|
|
|||
|
with:
|
|||
|
|
|||
|
In 5.15 Function Declaration / Dynamic Context Processing / rule 1 / premise 2, replace:
| dynEnv1 = dynEnv + funcDefn(expanded-QName() => (Expr)) |
with:
| dynEnv1 = dynEnv + funcDefn(expanded-QName,0 => (Expr)) |
In 5.15 Function Declaration / Dynamic Context Processing / rule 2 / premise 6+7+8, replace:
| [SequenceType1]sequencetype = Type1 |
| ... |
| [SequenceTypen]sequencetype = Typen |
| dynEnv1 = dynEnv + funcDefn(expanded-QName(Type1,...,Typen) => ( Expr , Variable1 , ···, Variablen)) |
with:
| dynEnv1 = dynEnv + funcDefn(expanded-QName,n => ( Expr , Variable1 , ···, Variablen)) |
In B Index of judgments / Auxiliary judgments, replace:
dynEnv1 ; AnyURI |- (expanded-QName1(Type1,1, ..., Type1,n)), ···, (expanded-QNamek(Typek,1, ..., Typek,n)) =>import_functions dynEnv2
with:
dynEnv1 ; AnyURI |- (FunctionKey1,FunctionSig1) ... (FunctionKeyn,FunctionSign) =>import_functions dynEnv2
Superseded by Erratum FS.E011
See Bug 1660
Put 'Expr' in parentheses when it occurs as a function argument.
16 Jul 2005: Proposed
16 Apr 2006: Accepted
18 Sep 2007: Issued
In 4.7.3.2 Dynamic Evaluation / Dynamic Evaluation / rule 1 / premise 1, replace:
dynEnv |- fs:item-sequence-to-untypedAtomic(
Expr) =>
AtomicValue |
with:
dynEnv |- fs:item-sequence-to-untypedAtomic((
Expr)) =>
AtomicValue |
In 4.7.3.2 Dynamic Evaluation / Dynamic Evaluation / rule 2 / premise 4, replace:
dynEnv |- fs:item-sequence-to-untypedAtomic(
Expr2) => AtomicValue2 |
with:
dynEnv |- fs:item-sequence-to-untypedAtomic((
Expr2)) => AtomicValue2 |
See Bug 1746
Fix typo in function signature.
19 Jul 2005: Proposed
21 Feb 2006: Accepted
18 Sep 2007: Issued
In 7.1.2 The fs:convert-simple-operand function, in the function signature, replace:
fs:convert-simple-operand(
...
) as xs:anyAtomicTypeAtomic *with:
fs:convert-simple-operand(
...
) as xs:anyAtomicType *See Bug 1647
Complete the changes entailed by adding a local-namespaces component to the Core CompElemConstructor.
16 Jul 2005: Proposed
22 Jul 2005: Accepted
18 Sep 2007: Issued
In 4.7.3.1 Computed Element Constructors / Normalization / rules 2+3, add an empty brace-pair to each Core CompElemConstructor. Specifically, replace:
element QName
{ fs:item-sequence-to-node-sequence((
[Expr]Expr)) }
|
with:
element QName
{ fs:item-sequence-to-node-sequence((
[Expr]Expr)) }
{}
|
and replace:
element {
fn:data(([Expr1]Expr)) }{
fs:item-sequence-to-node-sequence((
[Expr2]Expr)) }
|
with:
element {
fn:data(([Expr1]Expr)) }{
fs:item-sequence-to-node-sequence((
[Expr2]Expr)) } {}
|
In 4.7.3.1 Computed Element Constructors / Dynamic Evaluation / para 2, replace:
First, the element's content expression is partitioned into the local namespace declarations and all other expressions, and the local namespace declarations are evaluated, yielding a sequence of namespace bindings.
with:
First, the constructor's local namespace declarations are evaluated, yielding a sequence of namespace bindings.
In 4.7.3.1 Computed Element Constructors / Dynamic Evaluation / rule 1, add an empty brace-pair to the Core CompElemConstructor in the conclusion; that is, replace:
with:
In 4.7.3.1 Computed Element Constructors / Dynamic Evaluation / rule 2, replace:
|
|||||||||||
|
|
|||||||||||
statEnv; dynEnv |-
element QName { Expr } => element QName of type
xs:anyType { Value0 } { NamespaceBindings }
|
with:
|
||||||||||||||||||
|
|
||||||||||||||||||
statEnv; dynEnv |-
element QName { Expr } { LocalNamespaceDecls }
=> element
QName of type xs:anyType { Value0 } { NamespaceBindings }
|
In 4.7.3.1 Computed Element Constructors / Dynamic Evaluation / rule 3, replace:
with:
See Bug 3864
Both Core and Formal grammars had symbols 'NamespaceBinding' and 'NamespaceBindings'. To avoid confusion, we rename the Core symbols 'NamespaceBinding[s]' as 'LocalNamespaceDecl[s]', changing all occurrences of the former to the latter. At the same time, we introduce a production for LocalNamespaceDecls (currently assumed).
26 Oct 2006: Proposed
15 Sep 2007: Accepted
17 Sep 2007: Issued
In 4.7.3.1 Computed Element Constructors / Core Grammar and A.1 Core BNF / Non-Terminals, replace:
| [67 (Core)] | CompElemConstructor |
::= | "element" (QName | ("{"
Expr "}")) "{" ContentExpr "}" "{" NamespaceBinding* "}" |
| [68 (Core)] | NamespaceBinding |
::= | "namespace" NCName "{"
URILiteral "}" |
with:
| [67 (Core)] | CompElemConstructor |
::= | "element" (QName | ("{"
Expr "}")) "{" ContentExpr "}" "{" LocalNamespaceDecls
"}" |
| [98 (Core)] | LocalNamespaceDecls |
::= | LocalNamespaceDecl* |
| [68 (Core)] | LocalNamespaceDecl |
::= | "namespace" NCName "{"
URILiteral "}" |
In 4.7.1.2 Namespace Declaration Attributes / Normalization, 4.7.3.1 Computed Element Constructors / Notation, and 4.7.3.1 Computed Element Constructors / Static Type Analysis), change each occurrence of NamespaceBinding and NamespaceBindings to LocalNamespaceDecl and LocalNamespaceDecls respectively.
See Bug 1641
See Bug 3896
Make normalization of DirAttributeValue more explicit.
15 Jul 2005: Proposed
22 Jul 2005: Accepted
10 Sep 2007: Issued
In 4.7.1.1 Attributes / Notation / para 1, where we list the mapping rules, add [] DirAttributeValue and [] AttributeCharsUnit.
In 4.7.1.1 Attributes / Notation, replace:
| [87 (Formal)] | AttributeContentUnits |
::= | AttributeContentUnit* |
| [88 (Formal)] | AttributeContentUnit |
::= | EscapeQuot |
QuotAttrValueContent |
with:
| [87 (Formal)] | AttributeContentUnits |
::= | AttributeContentUnit* |
| [88 (Formal)] | AttributeContentUnit |
::= | AttributeCharsUnit | EnclosedExpr |
| [91 (Formal)] | AttributeCharsUnit |
::= | (QuotAttrContentChar |
AposAttrContentChar |
EscapeQuot | EscapeApos | PredefinedEntityRef |
CharRef | "{{" |
"}}")+ |
An AttributeCharsUnit is required to be maximal, i.e., it must extend as far as possible in both directions. In other words, an AttributeContentUnits must not contain two adjacent AttributeCharsUnits.
Also, make the same changes to productions in A.2 Formal BNF.
In 4.7.1.1 Attributes / Normalization, replace:
|
||
| == | ||
| attribute Prefix:LocalPart { [AttributeContentUnits]AttributeContent} |
with:
|
||
| == | ||
| attribute Prefix:LocalPart { [ [DirAttributeValue ]DirAttributeValue ]AttributeContent } |
The effect of [DirAttributeValue ]DirAttributeValue is not specified formally; informally, it partitions the content of DirAttributeValue into a sequence of AttributeContentUnits, each of which is either an enclosed expression (EnclosedExpr) or a maximal run of character content (AttributeCharsUnit). These content units are then normalized via []AttributeContent, which is defined below.
In 4.7.1.1 Attributes / Normalization, replace:
Literal characters, escaped curly braces, character references, and predefined entity references in attribute content are treated as in element content. In addition, the normalization rule for characters in attributes assumes:
that an escaped single or double quote is converted to an individual single or double quote.
The following normalization rules take the longest consecutive sequence of individual characters that include literal characters, escaped curly braces, escaped quotes, character references, predefined entity references, and escaped single and double quotes and normalizes the character sequence as a string.
| [( Char | CharRef | EscapeQuot | EscapeApos | PredefinedEntityRef ) +]AttributeContentUnit |
| == |
fn:codepoints-to-string(( Char |
CharRef | EscapeQuot | EscapeApos |
PredefinedEntityRef )+)
|
with:
The next two rules specify the normalization of each attribute-content unit via []AttributeContentUnit.
We normalize an AttributeCharsUnit (i.e., a maximal run of attribute-content characters, including literal characters, character references, predefined entity references, escaped curly braces, and escaped single and double quotes) by converting it into a string literal.
| [ AttributeCharsUnit ]AttributeContentUnit |
| == |
| [ AttributeCharsUnit ]AttributeCharsUnit |
The effect of [AttributeCharsUnit]AttributeCharsUnit is not specified formally; informally, it unescapes any escaped braces or quotes, performs attribute value normalization as specified in Section 3.7.1.1 AttributesXQ, and then represents the resulting string value as a string literal.
Bug #1641: FS.E001
Bug #1647: FS.E003
Bug #1660: FS.E005
Bug #1680: FS.E008
Bug #1694: FS.E007
Bug #1715: FS.E006
Bug #1746: FS.E004
Bug #1754: FS.E013
Bug #1756: FS.E014
Bug #1757: FS.E026
Bug #1776: FS.E034
Bug #1783: FS.E015
Bug #3142: FS.E009
Bug #3184: FS.E006
Bug #3193: FS.E035
Bug #3194: FS.E006
Bug #3268: FS.E036
Bug #3655: FS.E029
Bug #3670: FS.E010
Bug #3758: FS.E011
Bug #3760: FS.E011
Bug #3771: FS.E012 FS.E029 FS.E031
Bug #3818: FS.E021
Bug #3847: FS.E016
Bug #3861: FS.E037
Bug #3865: FS.E039
Bug #3866: FS.E040
Bug #3868: FS.E041
Bug #3873: FS.E044
Bug #3875: FS.E006
Bug #3876: FS.E045
Bug #3879: FS.E046
Bug #3882: FS.E047
Bug #3883: FS.E048
Bug #3886: FS.E050
Bug #3895: FS.E052
Bug #3896: FS.E001
Bug #3946: FS.E022
Bug #4189: FS.E059
Bug #4242: FS.E018
Bug #4261: FS.E018
Bug #4273: FS.E061
Bug #4371: FS.E017
Bug #4447: FS.E053
Bug #4512: FS.E018
Bug #4578: FS.E019
Bug #4581: FS.E018
Bug #4593: FS.E054
Bug #4601: FS.E055
Bug #4766: FS.E020
Bug #4841: FS.E024
Bug #4869: FS.E029
Bug #5129: FS.E018
Bug #5254: FS.E058
Bug #5452: FS.E062
Bug #5459: FS.E033
Bug #5460: FS.E033
Bug #5601: FS.E025
Bug #5651: FS.E027
Bug #5670: FS.E028
Bug #5747: FS.E032
Bug #5986: FS.E030
Bug #6005: FS.E051
Bug #6007: FS.E056
Bug #6160: FS.E057
Bug #6538: FS.E060
2.1.4 Notations for inference rules: FS.E037
2.3.1 Formal values / Notation: FS.E038
2.3.2 Examples of values: FS.E039
2.4.1 XML Schema and the [XPath/XQuery] Type System: FS.E040
2.4.2 Item types: FS.E022
2.4.3 Content models / Notation: FS.E041
2.4.4 Top level definitions: FS.E020 FS.E036 FS.E042 FS.E043
2.4.5 Example of a complete Schema: FS.E042
2.5 Functions and operators: FS.E044
3.1.1 Static Context / Notation: FS.E006 FS.E009
3.1.1 Static Context / Notation / statEnv.funcType: FS.E006
3.1.2 Dynamic Context / dynEnv.funcDefn: FS.E006
3.2.1 Processing model: FS.E017
3.2.2 Normalization mapping rules / Notation: FS.E045 FS.E051
3.5.1 Predefined Schema Types: FS.E022 FS.E042
3.5.4 SequenceType Matching / Normalization: FS.E022
4 Expressions / Static Type Analysis: FS.E046
4.1.5 Function Calls / Dynamic Evaluation: FS.E006 FS.E049
4.1.5 Function Calls / Normalization: FS.E008 FS.E047 FS.E051
4.1.5 Function Calls / Notation 1: FS.E051
4.1.5 Function Calls / Static Type Analysis: FS.E048
4.2 Path Expressions / Normalization: FS.E021
4.2.1 Steps / Dynamic Evaluation: FS.E050
4.2.1 Steps / Normalization: FS.E024
4.2.1.1 Axes / Normalization: FS.E060
4.3.2 Filter Expressions / Normalization: FS.E019 FS.E024
4.5.2 General Comparisons / Normalization: FS.E055
4.7.1 Direct Element Constructors / Introduction: FS.E052
4.7.1 Direct Element Constructors / Normalization: FS.E011 FS.E029 FS.E052
4.7.1 Direct Element Constructors / Notation 1: FS.E052
4.7.1 Direct Element Constructors / Notation 2: FS.E052
4.7.1.1 Attributes: FS.E001
4.7.1.1 Attributes / Normalization: FS.E011 FS.E031
4.7.1.2 Namespace Declaration Attributes / Normalization: FS.E002
4.7.1.4 Boundary Whitespace: FS.E052
4.7.3.1 Computed Element Constructors / Core Grammar: FS.E002
4.7.3.1 Computed Element Constructors / Dynamic Evaluation: FS.E003 FS.E022 FS.E023 FS.E029
4.7.3.1 Computed Element Constructors / Normalization: FS.E003
4.7.3.1 Computed Element Constructors / Notation: FS.E002
4.7.3.1 Computed Element Constructors / Notation 2: FS.E029
4.7.3.1 Computed Element Constructors / Static Type Analysis: FS.E002 FS.E012 FS.E022 FS.E023
4.7.3.2 Computed Attribute Constructors / Dynamic Evaluation: FS.E005 FS.E011
4.7.3.2 Computed Attribute Constructors / Normalization: FS.E031
4.7.3.2 Computed Attribute Constructors / Static Type Analysis: FS.E023 FS.E031
4.7.3.3 Document Node Constructors / Dynamic Evaluation: FS.E022 FS.E023 FS.E029
4.7.3.3 Document Node Constructors / Normalization: FS.E029
4.7.3.3 Document Node Constructors / Static Type Analysis: FS.E029
4.7.3.4 Text Node Constructors / Normalization: FS.E030
4.7.3.5 Computed Processing Instruction Constructors / Static Type Analysis: FS.E022
4.8.1 FLWOR expressions / Normalization: FS.E028
4.12.4 Castable / Dynamic Evaluation: FS.E032
4.12.4 Castable / Normalization: FS.E032
4.12.4 Castable / Notation: FS.E032
4.12.5 Constructor Functions / Normalization: FS.E008
4.12.5 Constructor Functions / Notation: FS.E008
4.13 Validate Expressions / Static Type Analysis: FS.E023 FS.E058
5 Modules and Prologs / Dynamic Evaluation: FS.E007
5 Modules and Prologs / Notation 3: FS.E006
5 Modules and Prologs / Static Context Processing: FS.E007
5 Modules and Prologs / Static Type Analysis: FS.E007
5.10 Schema Import / Static Context Processing: FS.E042
5.11 Module Import / Notation 1: FS.E006
5.11 Module Import / Notation 2: FS.E006
5.11 Module Import / Notation 3: FS.E006
5.14 Variable Declaration / Static Context Processing: FS.E035
5.15 Function Declaration / Dynamic Context Processing: FS.E006
5.15 Function Declaration / Normalization: FS.E051
7.1 Formal Semantics Functions: FS.E021
7.1.1 The fs:convert-operand function / Static Type Analysis: FS.E057
7.1.2 The fs:convert-simple-operand function: FS.E004
7.1.5 The fs:item-sequence-to-node-sequence function: FS.E029
7.1.5 The fs:item-sequence-to-node-sequence function / Static Type Analysis: FS.E012 FS.E022 FS.E023 FS.E029
7.1.6 The fs:item-sequence-to-node-sequence-doc function: FS.E029
7.1.6 The fs:item-sequence-to-node-sequence-doc function / Static Type Analysis: FS.E022 FS.E023
7.1.7 The fs:item-sequence-to-untypedAtomic function: FS.E031
7.1.7 The fs:item-sequence-to-untypedAtomic function / Dynamic Evaluation: FS.E031
7.1.7 The fs:item-sequence-to-untypedAtomic function / Introduction: FS.E031
7.1.14 The fs:item-at function: FS.E024
7.2.1 The fn:last context function / Dynamic Evaluation: FS.E013
7.2.2 The fn:position context function / Dynamic Evaluation: FS.E013
7.2.3 The fn:abs, fn:ceiling, fn:floor, fn:round, and fn:round-half-to-even functions: FS.E033
7.2.3 The fn:abs, fn:ceiling, fn:floor, fn:round, and fn:round-half-to-even functions / Static Type Analysis: FS.E014
7.2.4 The fn:boolean function: FS.E027
7.2.4 The fn:boolean function / Static Type Analysis: FS.E026 FS.E027
7.2.5 The fn:collection and fn:doc functions / Static Type Analysis: FS.E022 FS.E023
7.2.6 The fn:data function / Static Type Analysis: FS.E022 FS.E023 FS.E061
7.2.10 The fn:min, fn:max, fn:avg, and fn:sum functions: FS.E033
7.2.13 The fn:subsequence function: FS.E024
8.1.3 Element and attribute name lookup (Dynamic) / Semantics 1: FS.E023
8.1.3 Element and attribute name lookup (Dynamic) / Semantics 2: FS.E023
8.1.4 Element and attribute type lookup (Static) / Semantics 1: FS.E023
8.1.4 Element and attribute type lookup (Static) / Semantics 2: FS.E023
8.1.7 Type adjustment / Semantics: FS.E022
8.1.8 Builtin attributes: FS.E042
8.1.9 Type expansion: FS.E059
8.1.9 Type expansion / Semantics: FS.E059
8.1.10 Union interpretation of derived types / Notation: FS.E059
8.1.10 Union interpretation of derived types / Semantics: FS.E059
8.2.2.1.3 Inference rules for the child axis / Semantics: FS.E022 FS.E023
8.2.2.1.4 Inference rules for the attribute axis / Semantics: FS.E022 FS.E023
8.2.2.1.5 Inference rules for the parent axis / Semantics: FS.E022 FS.E023
8.2.2.1.6 Inference rules for the namespace axis / Semantics: FS.E062
8.2.2.1.9 Inference rules for the ancestor axis / Semantics: FS.E023
8.2.2.2 Dynamic semantics of axes / Semantics: FS.E034
8.2.3.1.1 [Static Semantics of] Name Tests: FS.E018
8.2.3.1.2 Kind Tests / Attribute kind test: FS.E023
8.2.3.1.2 Kind Tests / Element kind test: FS.E023
8.2.3.1.2 Kind Tests / Processing instruction, comment, and text kind tests: FS.E022
8.3.1 Matches / Semantics: FS.E022
8.4 Judgments for FLWOR and other expressions on sequences: FS.E015
8.4 Judgments for FLWOR and other expressions on sequences / Introduction: FS.E053
8.4 Judgments for FLWOR and other expressions on sequences / Semantics 1: FS.E057
8.4 Judgments for FLWOR and other expressions on sequences / Semantics 2: FS.E054
8.5.1 Type Promotion / Semantics: FS.E010
8.6.1 Elements in validation mode / Semantics: FS.E023
A.1 Core BNF / Non-Terminals: FS.E002
A.2 Formal BNF: FS.E001 FS.E022 FS.E036 FS.E041 FS.E042
A.2 Formal BNF / Non-Terminals: FS.E006 FS.E009
B Index of judgments: FS.E029 FS.E032 FS.E033
B Index of judgments / Auxiliary judgments: FS.E006 FS.E008
C.1 Functions and Operators used in the Formal Semantics: FS.E024 FS.E031
C.2 Mapping of Overloaded Internal Functions / Notation 2: FS.E056
C.2 Mapping of Overloaded Internal Functions / Notation 2 / Binary Operators table: FS.E010 FS.E016 FS.E025 FS.E053
D.1.3 Main mapping rules / Notation: FS.E051
D.2.1 Schema / Notation: FS.E051
D.2.1 Schema / Schema mapping: FS.E051
D.3.1 Global attributes declarations / Schema mapping: FS.E051
D.3.2 Local attribute declarations / Schema mapping: FS.E051
D.4.1 Global element declarations / Schema mapping: FS.E051
D.4.2 Local element declarations / Schema mapping: FS.E051
D.5.1 Global complex type / Schema mapping: FS.E051
D.5.2 Local complex type / Schema mapping: FS.E051
D.5.3 Complex type with simple content / Notation: FS.E051
D.5.3 Complex type with simple content / Schema mapping: FS.E051
D.5.4 Complex type with complex content / Schema mapping: FS.E051
D.9.1 All groups / Schema mapping: FS.E051
D.9.2 Choice groups / Schema mapping: FS.E051
D.9.3 Sequence groups / Schema mapping: FS.E051
D.10.1 Element reference / Schema mapping: FS.E051
D.11.1 Attribute wildcards / Schema mapping: FS.E051
D.11.2 Element wildcards / Schema mapping: FS.E051
D.15.1 Global simple type definition / Schema mapping: FS.E051
D.15.2 Local simple type definition / Schema mapping: FS.E051
D.15.3 Simple type content / Notation: FS.E051
D.15.3 Simple type content / Schema mapping: FS.E051
F.1.1 Type resolution / Semantics: FS.E036
(Core) CompElemConstructor: FS.E002
(Core) LocalNamespaceDecl: FS.E002
(Core) LocalNamespaceDecls: FS.E002
(Core) NamespaceBinding: FS.E002
(Core) NamespaceBindings: FS.E002
(Formal) AttributeCharsUnit: FS.E001
(Formal) AttributeContentUnit: FS.E001
(Formal) ElementContentType: FS.E022
(Formal) FunctionKey: FS.E006
(Formal) FunctionSig: FS.E009
(Formal) TypeList: FS.E009