Changes applied as follows. Marking resolved since this is editorial.

- 3.14.2 para starting "This mechanism" has opening sentence "[...] applies to [...] and to all attributes that are in no namespace". While later LRE's are mentioned (but not data elements), it might be clearer to say "and to all attributes that are in no namespace and are defined in this specification". Or something along those lines.

The intended meaning was "applies to all attributes in the stylesheet where the attribute name is in no namespace and the parent element is in the XSLT namespace." Will clarify accordingly.

- 3.11, opening para above bulleted list starts with "When an element...", then each item in the list starts with non-capital "if the element" and ends with " then the element...". Instead of "if the" I would propose to use "and the", because otherwise the sentences do not seem to combine.

I have capitalised the "if the" bullets as they are all complete sentences.

- 6.7.1, the para on built-in text copy rules talks about nodes and atomic values, and then concludes only about the context node, which can be absent: "The built-in template rule for text and attribute nodes and atomic values returns a text node containing the string value of the context node. It is effectively:"
Suggestion: "The built-in template rule for text and attribute nodes and atomic values returns a text node containing the string value of the context *item*. It is effectively:"

Already fixed (atomic values are now handled separately since it is not possible to define a match pattern as a union of a selection pattern and a predicate pattern).

- 8.3, first list, #5: "[...]and may be caught by a containing xsl:try instruction.". Does containing here means "wrapping", "ancestore" or "outer"? It is not clear to me what the object for "containing" is.
It means an xsl:try instruction that is an ancestor of the xsl:result-document insttruction. But while the sentence is true (it may be caught be a containing xsl:try) it is incomplete (it can also be caught by a non-containing xsl:try). Changing it to say "... and may be caught (for example by an xsl:try instruction that contains the xsl:result-document instruction).

- 8.3.2, 2nd example, "unvalidated tree", should this be "invalid tree" or "non-validating tree"?
No, it means what it says: the tree that has not been validated; distinguishing it from the other tree, which has been validated. I can't think of a better way of saying this, and as it's only an example I propose no change.

- 9.7, under "Statically known function signatures" in the table, para starts: "The core functions defined in [FO]". The definition for "core functions" was updated to include map functions, but the text was not. I think we should remove "defined in [FO]" to avoid this ambiguity.
Agreed.

- 9.7, static expressions are also used now in shadow attributes, this notion is not yet reflected here.
Agreed, fixed.

- 10, definition of "invocation construct", misses fn:key.
- same in C Glossary
I think this is intentional. key() is more like a variable reference; it does not "cause" the execution of the xsl:key use or match attributes (in the sense, for example, that try/catch could catch errors during their validation). I'm not sure whether acc-before and acc-after shouldn't be excluded from the list for the same reason. There are probably a number of edge cases here that could be better defined, e.g. the interaction of accumulators and try/catch. I don't propose to tackle that right now.

- 10, definition of "invocation constructs", it looks like the closing "]" comes too soon (should be after the dot, including all items).
- same in C Glossary
Already fixed.

- 14.2.1, last Rule: "The current group is initially absent during the evaluation of global variables and stylesheet parameters.". This should include initial-value of xsl:accumulator. Same is true for fn:current-grouping-key, fn:current-merge-group, fn:current-merge-key.
I've been looking at the table in 5.4.4 and realising it's pretty muddled about exactly what it means when it says "initial setting". Too big a job to tidy it up now, I'll apply the changes you suggest as a quick fix.

- 15.6, see previous point, it also applies to the last para of the opening section
This paragraph is essentially redundant, so I've reduced it to a Note and simplified it.

- 19.8.1, item 1.c.ii: "the operand is not grounded" should probably be "the posture of the operand is not grounded" (an operand itself cannot be grounded, its posture can)
We often talk of the posture and sweep of an operand, e.g. 1a(ii) in the same section. I think this is legitimate: in the definition of "operand" (which we don't often link to...) we say "an operand is a construct..", so it's reasonable to talk of properties of the construct as properties of the operand.

- 19.8.8.18: 2nd para. Normally we talk of the "static type" or "statically known item type" of a construct. This is omitted here. I think it ought to be made explicit.
Yes. Also changed it to use U{document-node()} notation.

- 19.8.9, just before the examples "A pattern that is not motionless is classified as free-ranging.". This is redundant, as in the first para of this section we already say "The sweep of a pattern is either motionless or free-ranging.".
Yes it's redundant, but I think it's helpful.

- 19.8.7.6, text mentions FilterExpr (1x in whole doc), but that production does not exist. Should probably be "a PostfixExpr[XP30] that also is a filter expression[XP30]".
Changed it to say "a filter expression (see [xpath 3.2.1])".

- 19.10 Definition of "guaranteed streamable" says "as defined by the analysis in this specification.", I think this is too vague. Perhaps: "as defined by the analysis in this specification under section 19. Streamability" (or: "as defined in this section.", which is terminology used elsewhere)
This has been raised before, and we ended up with the references at the start of 19.10. I don't think it's easy to improve further. "This section" is more ambiguous than "this specification".

- XTSE3430: last part of the sentence does not explicitly state that it is meant to apply to streamed processing. I suggest: "is to handle this situation *either* by processing the stylesheet without streaming, *or with streaming*, by making use of processor extensions to the streamaiblity rules where available.
I think the previous paragraph makes it clear. The error description is merely recapitulating the previous para and its bullet points.