This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In discussing bug 10664 this morning, the WG agreed that it was probably a mistake to say that if xsi:type fails to resolve, then the element carrying it is not locally valid against ANY type. Element Locally Valid (Type) of section 3.3.4.4 now says this for elements without a governing element declaration (and there may be an analogous rule elsewhere for element that do have a governing element declaration). We may wish (for compatibility or other reasons) to ensure that any element carrying an unresolvable xsi:type attribute is invalid, but if so then it needs to be done in some other way. The editors were instructed to look for and propose a fix (or to come back with the news that no fix is available).
A wording proposal for this issue is at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b11764.html It removes the clause about xsi:type from the definition of local validity against a type. Note that because the rules for attribute validity require xsi:type to resolve successfully, a failure to resolve will result in (a) the xsi:type attribute itself having [validity] = invalid, and therefore (b) the parent element also having [validity] = invalid, if the parent element is strictly assessed. (If the parent element is not strictly assessed, having an invalid child has no effect.) It also weakens and shortens the clause about xsi:type in the definition of local validity against an element declaration: the clause saying that xsi:type must resolve is gone (it was in any case circular to require an instance-specified type definition not to be absent, since if the QName doesn't resolve there is no instance-specified type definition at all). The clause saying that the instance-specified type definition must override the selected type definition is still present, since (a) it is not otherwise enforced, and (b) it does seem like a plausible part of local validity against an element declaration to say that the element can't have an xsi:type naming an incompatible type. There is also a note added to the definition of governing attribute declaration, to help readers remember that the governing attribute declaration of xsi:type will always be the built-in declaration unless the processor stipulates a different declaration (in which case the invoker bears full responsibility for any non-intuitive results).
RESOLVED: adopt the proposal as presented.
The decision reported in comment 2 has been implemented.