3887 2006-10-30 15:14:34 +0000 3.10.4 errors in wildcard namespace check 2017-01-19 11:27:42 +0000 1 1 1 Unclassified XML Schema Structures: XSD Part 1 1.0 only All All NEW http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#cvc-wildcard-namespace P2 normal --- 1 dsb m_a_s_7 mostafa.shahdadi m_a_s_7 slave.loren www-xml-schema-comments oldest_to_newest 12660 0 dsb 2006-10-30 15:14:34 +0000 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.) 12889 1 sandygao 2006-11-09 19:26:16 +0000 Marking this bug as 1.0 only, as the cited text has changed in 1.1 drafts.