1) In section 3.4, third bullet from top, "Constraining elements and attributes to exist, not to exist, or to have specified values, with Assertion (§2.2.4.2)" are not the words I would use to describe CC. In my mind, the purpose of CC and of co-constraints in general is to subject the validity (and/or type) of the defined element/type to the presence, absence or value of other elements and attributes. Proposal: "constraining elements and attributes to the presence, absence or value of other elements and attributes".

2) Section 3.4.1, way down (just before 3.4.2): "{assertions} constrain elements and attributes to exist, not to exist, or to have specified values." Same as before, with now the additional problem that, given the context and the sentences immediately before, by the way I read it, it seems to imply that only direct children (elements and attributes) of the complex type are affected by assertions. This is not true and could be misleading. Proposal: "{assertions} constrain the validation of element information items to the successful verification of (rules about) the presence, absence or value of elements and attributes in the local subtree".

3) 3.4.2, property mapping, first block: "{assertions} - A sequence whose members are Assertions drawn from the following sources, in order: 1 The {assertions} of the {base type definition}. 2 Assertions corresponding to all the <assert> and <report> element information items among the [children], if any, in order." The description of derivation of types with assertions is never discussed as such, but it is described implicitly in two separate pieces. This is one: it is a bit tiny, and misleading in part. In fact, the order of the assertions is never relevant. Derived types must simply obey to the sequence of ALL assertions, in any order, whether they are contained in the base type definition or in any of the further derivations. Proposal: add somewhere else (I'll propose) something about derivation of types with assertions, and remove the words "in order", which are present twice.

4) 2.4.2 farther down, at the end of the table: "Note: If the {base type definition} is a complex type definition, then the {assertions} always contain members of the {assertions} of the {base type definition}, no matter which alternatives are chosen in the XML representation, <simpleContent> or <complexContent>, <restriction> or <extension>." Correct, but again tells only half of the story of derivation of types with assertions.

5) 3.4.4 Item #5 "The element information item is ·valid· with respect to each of the {assertions} as per Assertion Satisfied (§3.12.4)." This is the only part of the discussion about derivation of types with assertions that is presented. This is also tiny and not well presented. Suggestion: keep the wording as it is, and add a note saying something like: "When both the definition of the base type and the definition of the derived type have assertions, the overall list of assertions to be evaluated is composed by both lists. All and each assertion must be evaluated independently. The first assertion to fail yields a validation error. The order of evaluation is not relevant and the lists of assertions can have identical terms (which can be evaluated only once).

6) 3.4.6 Second block: Schema Component Constraint: Derivation Valid (Extension). No discussion about derivation by extension of types with assertions is provided. Suggestion: add item "3: The assertions of the complex type definition are added to the assertions of the base type definitionto form the full list of assertions to be evaluated."

7) 2.4.6 Third Block:  Schema Component Constraint: Derivation Valid (Restriction, Complex). Numbering is odd in my copy, but down and well hidden there is item "7 The {assertions} of the {base type definition} is a prefix of the {assertions} of the complex type definition itself.". This is unclear to me. What is a prefix? Why put it in terms of the assertions of the base type definition instead of the assertions of the complex type definition? Proposal:  "7: The assertions of the complex type definition are added to the assertions of the base type definitionto form the full list of assertions to be evaluated."

3.12.1 The restriction of XPath 2.0 is overly restrictive. I do not understand especially why no arithmetics is allowed on values, and why predicates can only refer to attributes on the current element. This excludes things such as
<assert test=".//p[@class='foobar']"/>  -- at least one paragraph of class foobar must exist
or
<assert test=".//table[count(tr) eq (count(tr[1]/td)+1)]"/> -- I must have one row for every column, plus one row for table headings.

Both requirements seem quite natural, straightforward, and providing no problem when implemented in streaming. At least I find.

3.12.1 Also the function list is overly restrictive. I suggest we allow all those functions for which we have no strong reason for exclusion, rather than the other way round.

3.12.5 Assertion Information Set Contributions: Possibly we could add which assertion has failed in case of non valid results?