1. In the paragraph "The EQName production allows a QName to be written in one of three ways:" several sentences are missing full stops; and it would probably be better to write "uri" at the start of a sentence as "URI" or "Namespace URI".

2. In the following paragraph the first sentence "The EQName production allows expanded QNames to be specified using either a QName or a URIQualifiedName, which allows the namespace URI to be specified as a literal. " is a restatement of what goes immediately before and could be dropped. Then start the para with "The namespace URI value *in a URIQualifiedName* is whitespace normalized...

3. The definition of "lexical QName" is misplaced at the end of this paragraph. It should probably go into the separate para above this one.

4. In the paragraph starting "This document uses the following namespace prefixes to represent the namespace URIs with which they are listed. Use of these namespace prefix bindings in this document is not normative.": (a) the list of prefixes seems incomplete - what about map, and array (and for completeness, math)?
- I think that when we write, for example, "$array($key) is equivalent to array:get($array, $key)" then there is a sense in which the prefix binding is indeed normative. What I think we mean to say is "Although these prefixes are used within this specification to refer to the corresponding namespaces, these bindings will not necessarily be present in the static context of every XPath expression, and XPath authors are free to use different prefixes for these namespaces, or to bind these prefixes to different namespaces".

5. The two paragraphs starting with "Element nodes have a property called in-scope namespaces." are misplaced. We talked about the data model, then we talked about some basics in the grammar, now we're talking about the data model again, but we didn't warn the user of the change of topic. The two paras would be better moved up the section to go with other stuff on the data model.

6. §2.1.1. (Probably out of scope for an editorial bug): Static context / statically known collations - there are no XPath expressions that require static knowledge of collation URIs.

7. §2.1.1. Statically-known-documents and statically-known-collections are written very much as if the mapping is expected to be an enumeration of known URIs. But I think it's perfectly valid to read it as a functional mapping, including for example a rule about the type of documents whose name ends in ".html". Perhaps a note saying that the mapping may be a function rather than an enumeration could be added?

8. §2.1.2 Dynamic context "that is available at the time the expression is evaluated". It would be nice to avoid the temporal language: "The dynamic context of an expression is defined as information that needed for the dynamic evaluation of an expression."

9. §2.1.2, para starting "Certain language constructs, notably the path operator E1/E2, the simple map operator, and the predicate E1[E2]," For symmetry, expand "the simple map operator E1!E2", and give a hyperlink.

10. §2.1.2 "The inner focus exists only while E2 is being evaluated. When this evaluation is complete, evaluation of the containing expression continues with its original focus unchanged" Again it would be nice to avoid the temporal language. With lazy evaluation, parallel processing etc this use of "while" and "when" is potentially misleading. Try "The inner focus is used only for the evaluation of E2. Evaluation of E1 continues with its original focus unchanged."

11. §2.2.1 Data model generation. The title of the section is wrong; W3C generates the data model, it doesn't happen as part of this process. (Unfortunately the title also appears on the diagram). What the process is actually describing is construction of a data model instance from external data sources.

12. §2.2.1 "Before an expression can be processed, its input data must be represented as an XDM instance." As a temporal statement, this is plain wrong. The processes can be concurrent (with streaming they are definitely concurrent). Change to "The input data for an expression needs to be represented as an XDM instance".

12a. Same sentence, "an XDM instance". We have defined "XDM instance" as a synonym for "value". But throughout this section we are clearly using the term to mean a set of values. For example, the Variable Values in the dynamic context is clearly a set of values (or XDM instances), not a single XDM instance. We either need to change the way we define the term or the way we use it. 

13. §2.2.3.1 " In XQuery 3.1 and XPath 3.1, the rules for static type inferencing are entirely implementation-defined." Implementation-defined or -dependent? Do we really want to require an implementation to publish its static type inferencing rules? (Speaking as an implementor, I have no intention of doing so.)

14. §2.2.3.1 and elsewhere. There are about 15 references to the "Static Typing Feature" all of which could usefully be hyperlinked to the definition of the term.

15. §2.2.3.2 "It occurs after completion of the static analysis phase." Again, temporal language that appears to preclude techniques such as JIT compilation. Change to "It is dependent on successful completion of the static analysis phase."

16. §2.2.4 talks of "the XDM instance" - see 12a above.

17. §2.3.1 para 3, stray whitespace towards end of para.

18. §2.3.1 para 9, "An implementation can raise a dynamic error for *a an* XPath expression"

19. Same para, more substantively, "query" should be "expression".

20. §2.3.4 refers to "Conditional, switch, and typeswitch expressions must not raise a dynamic error..." Switch and typeswitch expressions are XQuery-only.

21. §2.5 first note "XQuery continues to use". This spec is about XPath. The note is in any case unhelpful. Both XSD 1.0 and XSD 1.1 use the terms "type" and "datatype" pretty well interchangeably. Certainly in both cases "datatype" is used only in part 2, whereas our type system is equally concerned with the types of part 1.

22. §2.5.1 "[Definition: xs:error is a simple type with no value space, available defined in Section 3.16.7.3 xs:error XS11-1. can be used in the 2.5.4 SequenceType Syntax to raise errors.]" Some typo here around "available defined.".

23 § 2.5.5.2 penultimate bullet, "The ItemType array(T) matches any array in which the type of every entry is T." The things in an array are members, not entries.

24. §2,5,7 In the Note, ungrammatical sentence "Although the practical uses of xs:error as a sequence type are limited, but they do exist."