While on the subject of the whitespace facet:

(a) in section 4.3.6, in the following Note

Note: For more information on whiteSpace, see the discussion on white space normalization in Schema Component Details in [XSD 1.1 Part 1: Structures].

it would be helpful to provide a more precise link, specifically to section 3.1.4 in part 1

(b) also in 4.3.6, the clause

for any type ·derived· by ·facet-based restriction· from string the value of whiteSpace can be any of the three legal values

is not actually true, because the value cannot be "more restrictive" than the value on the built-in type from which it is (directly) derived

(c) in sections such as 3.4.1.1 (normalizedString) the following phrase appears in relation to the whitespace facet: "if the value given is at least as restrictive as the one shown"; however, the whitespace facet is not restrictive (despite it being categorised as a "constraining facet"), so it's hard to see how one value can be more restrictive than another; in fact, the rules for overriding one value with another are given in 4.3.6.4.

In practice most subtypes of xs:string have whiteSpace="collapse", so the statement that the value may be replaced with another value "if the value given is at least as restrictive as the one shown" is unhelpful and misleading; the only value that can appear on a subtype of xs:token, for example, is "collapse", which is the value that it would effectively have anyway.

Thank you; good points.

On (c), I think I disagree.  It seems intuitively clear to me (at
least) that the value 'collapse' is more restrictive than the 
value 'preserve', with 'replace' in the middle between them, if
only in the sense that moving from 'preserve' to 'replace' to 
'collapse' effectively removes literals from the lexical space.
(We noticed some time ago that the spec is not as clear or
explicit on this as it ought to be, but decided to let sleeping
dogs lie.  But regardless of whether, formally, the shift from 
'preserve' to 'replace' eliminates strings containing 
 from 
the lexical space, it at the very least makes them a lot harder
to write in a document.)  

Of course, its being clear to me is no indication that it will be
clear to any reader not steeped in years of WG casuistry.  But
I find it hard to formulate an effective revision here because I
have not been able to persuade myself to find the current
wording confusing or counter-intuitive.  Anyone who does find
the current wording unfortunate can help either by explaining 
as well as they can the nature of their confusion in more 
detail, or (perhaps more easily) by suggesting alternative 
wording they would find less confusing.

Fair enough. To me, "restrictive" and "constraining" suggest a restriction or constraint on the set of valid instance documents, and in that sense the whiteSpace facet is neither restrictive nor constraining.

(In reply to comment #3)
> Fair enough. To me, "restrictive" and "constraining" suggest a restriction or
> constraint on the set of valid instance documents, and in that sense the
> whiteSpace facet is neither restrictive nor constraining.

From comment #2:
>            But regardless of whether, formally, the shift from 
> 'preserve' to 'replace' eliminates strings containing 
 from 
> the lexical space, it at the very least makes them a lot harder
> to write in a document.)  

Note that the definition of the facet begins:  " [Definition:]   whiteSpace constrains the ·value space· of types ·derived· from string such that...."

Given that the stated purpose of whiteSpace is to constrain the value space, I think MSM's point of view must be the appropriate one.  Please let us not revisit yet again at this late date the option of rewriting whole sections for clarity.

MSM: on review it seems that a note to address the confusion with the terminology is in order.

A proposal intended to resolve this issue is now on the server at

  http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.b11961.html
  (member-only link)

 RESOLVED: adopt the proposal but the editor has freedom to improve on the Note:

The proposal mentioned in comment 6, which was adopted 22 April (comment 7), has been integrated into the status-quo document.

Michael, please close or reopen as needed.  Thanks.