The following are, I believe, minor changes that would improve flow, correct typos, and/or clarify things for the reader.  The working group is free to make any, all, or none of them.  I require no feedback, I can live with any of them being ignored.

2.1 Overview of XSD
from: This augmentation makes explicit information          implicit 
to  : This augmentation makes explicit information that was implicit 
Existing exp/word/imp juxtaposition makes my head hurt.

2.2.2.2 Element Substitution Group
from: XSD     provides a more powerful model              supporting
to  : XSD 1.1 provides a more powerful model than XSD 1.0 supporting

2.2.3.1 Model Group
from: items match         one of the particles
to  : items match exactly one of the particles
If you disagree, see the first paragraph of http://en.wikipedia.org/wiki/Disjunction 
for why the existing text is ambiguous unless the reader _happens_ to know you
are talking about <choice> in this veiled way.

2.2.3.2 Particle
"[Definition:]  A particle P is said to accept or recognize the members of L(P). Similarly, a term T  accepts or recognizes the members of L(T)."
Modulo the substitution of words like particle/P for model group/G, these Definitions (apparently of "X accepts" etc) are dups of those in the preceding section.
If the P/G difference is sufficient to make those different terms in your eyes, I think you will successfully fool most readers.

2.2.3.3 Attribute Use
"attribute declaration within a complex type definition is embedded within an attribute use"
This appears to say that attribute use components only correspond to embedded, not referenced, uses.  Just confirming that is so, I thought both embed/ref would result in attr-use.

2.2.4.2 Type Alternative
FYI: "A type-alternative component" name is not hyphenated everywhere in later sections, if it should be.

2.3 Constraints and Validation Rules - Schema Component Constraint
from: components at all.          Located in the 
to  : components at all. They are located in the 
Otherwise "Located..." sentence has no subject.  Alternative: ; l
also in 2.3 Constraints and Validation Rules - Schema Representation Constraint

3.1.3 The Mapping between XML Representations and Components
from: URI reference
to  : URI-reference
RFC 3986 appears to always hyphenate this, FYI.

3.2.2.2 Mapping Rules for Local Attribute Declarations
"...attribute declaration (see below)..."
I usually interpret this to mean the first "thing" below.  In this case you are referring to the second.  Perhaps a link?

3.2.2.2 Mapping Rules for Local Attribute Declarations
from: the {attribute declaration} of the           attribute use just described,
to  : the {attribute declaration} of the preceding attribute use,
Alternative: "above"

3.3.4.4 Element Locally Valid (Type)
"...definition·, ·lax assessment·  is performed, ..."
I'm not sure how to fix this.  It feels like there is a missing connector before lax assessment is performed, but the preceding but-and-otw-neither-nor maze could be defeating my attempts to properly group the terms.

3.3.5.1 Assessment Outcome (Element)
from: 1.2 otherwise invalid..
to  : 1.2 otherwise invalid.

3.3.5.4 Element Validated by Type - [type definition name]
from: the ·type definition·'s {name} property is
to  :    [·type definition·]. {name}          is
Note: {} might need to be [] I did not dig back to find the notation you introduced earlier for this kind of case.

3.3.5.4 Element Validated by Type - [type definition name]
from: The {name} of the ·type definition·, if the {name}  is not ·absent·.
to  : The {name} of the ·type definition·, if the {name}  is present     .
Might be worth a global scan for "not present" and "not absent", other examples of "not absent" definitely exist but I will not enumerate them here.
e.g. 3.3.4.3 Element Locally Valid (Element) Validation Rule: Element Locally Valid (Element) clause 1

3.4.2.3 Mapping Rules for Complex Types with Complex Content
"one with neither <simpleContent> nor <complexContent> as a child (discussed in Mapping Rules for Complex Types with Explicit Complex Content (§3.4.2.3.1))"
from: in Mapping Rules for Complex Types with Explicit Complex Content (§3.4.2.3.1))
to  : in Mapping Rules for Complex Types with Implicit Complex Content (§3.4.2.3.2))
Simple copy/(forgot to) tweak omission.  EXplicit covered 2x in this paragraph, IMplicit covered 0x.

3.4.2.3.1 Mapping Rules for Complex Types with Explicit Complex Content
FYI: formatting glitch, {derivation method} (in browser window on screen, not print) runs over box bottom's border

3.4.2.6 Examples of Complex Type Definitions
FYI: 2nd Example box uses different style (no "intro" text at top) than others surrounding it.

3.4.4.4 Attribution of Elements to Particles
from: attribute wildcards, particles and open contents on the other,
to  : attribute wildcards, particles and open content  on the other,

3.4.4.4 Attribution of Elements to Particles
"the {attribute declaration} of an Attribute Use, then the item is attributed to that attribute use"
I found myself, after the ibuprofen kicked in, wanting to use a different verb than attribute for this role, like assigned or mapped.  Then I noted that when defining context-determined decls later in this section, you do switch to "associate".  Changing "attribute to" -> "associate with" more widely (even globally) would be a clarifying action IMO.
Section 3.8.4.1 Language Recognition by Groups uses "match": "... the sequence of ·basic particles· which the [element] items of S match, in order, is a path of S in M."

3.4.5.1 Attribute Default Value
FYI: formatting glitch, evident in Firefox 2 and 3 on Windows XP (have not tested others).
2-item bullet list near end of section, first word "Add" of each item was bulls-eyed by the bullet
e.g. "Add the binding of P to N to..."

3.8.1 The Model Group Schema Component
"By 'indirectly' is meant particles... "

3.8.2 XML Representation of Model Group Schema Components
in XML Mapping Summary for Particle Schema Component tableau
from: A model group as given below:
to  : A model group as given below.

3.10.1 The Wildcard Schema Component
FYI: formatting glitch up-arrows appear around item 6 in the numbered list

3.10.1 The Wildcard Schema Component - {process contents} controls ... lax
"If the item has a uniquely determined declaration available, it must be ·valid· with respect to that definition,"
Notice the switch from decl to def in the same sentence.  Looks wrong from here.

3.10.4.2 Wildcard allows Expanded Name
FYI: formatting glitch up-arrows appear around item 2 in the numbered list, and around "Informally..."

3.10.6.2 Wildcard Subset
FYI: formatting glitch up-arrows appear around item 3 in the numbered list

3.11.4 Identity-constraint Definition Validation Rules - last parag
from: treated as equal , for purposes
to  : treated as equal,  for purposes

3.12.2 XML Representation of Type Alternative Schema Components
"type alternative schema componentType Alternative is"

3.13.4.1 Assertion Satisfied - 2.3.1.3 note 1
from: This clause provides type information to simple contents of elements,
to  : This clause provides type information to simple element content     ,

3.16.7.4 Built-in primitive datatypes
"primitives are supported" missing: datatypes
"primitive types can be supported" missing: data
"Types ·automatically known· to a processor, whether primitive or derived" missing(?) Data+t
"specify new primitive types" missing: data

4.2.4 Overriding component definitions - Schema Representation Constraint: Override Constraints and Semantics 2.2+
Numbering has little phoenetic value.  How about
from: call the overridden <schema> item D2
to  : call the overridden <schema> item Old
and
from: and the overriding item's parent <schema> item D1
to  : and the overriding item's parent <schema> item New
Another alternative: OI (old item) and NI

4.2.5 References to schema components across namespaces
from: components not within that document's target namespace
to  : components outside    that document's target namespace
Alternative: re-use existing term from next sentence = foreign target namespace (note: not formally defined, but I think fine)

4.2.5.1 Licensing References to Components Across Namespaces
"external component references" - nb: in italics, but not a [Definition:], though it sure looks like it wants to be one.
Harmonize with 4.2.5 text that uses "not inside" and "foreign".

4.3.2 How schema definitions are located on the Web
"This section introduces a set of normative conventions..."
normative conventions?  tilt

4.3.2 How schema definitions are located on the Web - bullet 1
"...·assessment· is undertaken on the document element information item of the specified document"
from: specified          document
to  : specified instance document
To distinguish from "schema document" which I get it is theoretically possible but not the usual intent.

4.3.2 How schema definitions are located on the Web - numbered item 3
FYI, in case unintentional, largely dups content in 1.3.1.2 and 2.6.x

4.3.2 How schema definitions are located on the Web - ex after numbered item 4
FYI: 2nd ns line is too long for 8.5x11 printing using default margins (FF2,3)
It is truncated after Transform.xs on the 2nd schemalocation.
This does occur in a few other places, will not enumerate them all.

5.1 Errors in Schema Construction and Structure
from: The three cases described above
to  : The two   cases described above
or, more durably,
to  : The       cases described above
(I realize you didn't expect a kind of Spanish Inquisition, Cardinal Biggles)

5.2 Assessing Schema-Validity
from: refers back to the ·validation root·. .
to  : refers back to the ·validation root·.