Regarding _XML_Schema_Part_1:_Structures_Second_Edition at
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/:


There seems to be an error in section 3.10.4.  Under "Validation Rule:
Wildcard allows Namespace Name" (at 
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#cvc-wildcard-namespace) 
it says:

    For a value which is either a namespace name or ·absent· to be
    ·valid· ...
      ...
      2.1 The constraint is a pair of _not_ and a namespace name or
          ·absent· ([Definition:]  call this the *namespace test*).
      2.2 The value must not be identical to the ·namespace test·.
      ...

Clause 2.2 will always be true:  The value will never be identical to
the namespace test, because a namespace name or ·absent· (the value)
will never be identical to any _pair_ (the namespace test).

I suspect that the problem is that the "this" in "Call this the
namespace test" was meant to refer to:

  a namespace name or ·absent·

instead of being interpretable as referring to:

   a pair of _not_ and a namespace name or ·absent·.

If that suspicion correct, then the wording "call this the *namespace
test*" should be changed to something less ambiguous.

(Obviously, if the problem is something else, then whatever the real
problem is should be fixed appropriately.)

[In the 2006-03-30 1.1 draft, the wording has changed a bit, but I don't
have time at the moment to analyze it to see how the change affects this
bug report's problem.]



At a more editorial level, that section also has a problem that still
appears in many places in the XML Schema documents.

Note how the existing wording says [asterisk emphasis added]:

    For a value ... to be ... ·valid· ... one of the following must be
    true:
    1 The constraint *must* *be* _any_.
    2 All of the following *must* *be* true:
      ...

instead of saying

    For a value ... to be ... ·valid· ... one of the following must be
    true:
    1 The constraint *is* _any_.
    2 All of the following *are* true:
      ...

Saying that something *is* true is significantly different than saying
that it *must* *be* true (i.e.., that it *is* *required* *to* *be* true
by some other rule).

Notice how the meaning of the existing wording is different from what
is intended.  Writing:

   for X to be valid it must be true that Y must be true

means:

   for X to be valid it must be true that Y is required to be true

(i.e., by some rule somewhere else).  It does not mean:

   for X to be valid it must be true that Y is true

Although this might sound like a nit, the many instances of this error
make the specification's text really hard to follow.


(By the way, notice that clause 3 shows the correct form [again, emphasis
added]:

    For a value ... to be ·valid· ... one of the following must be true:
    1 ...
    2 ...
    3 The constraint *is* a set, and the value *is* identical to one of
      the members of the set.

)

This type of error appears in many places in the text.  The next edition
and/or version should correct them.  (Probably any time a "must" has
within its scope another "must," there is a problem, although there
could be exceptions where one rule really does refer to the effects of
another rule.)