11764 2011-01-14 18:40:01 +0000 Unresolved xsi:type should not affect validity against a type 2011-03-23 19:41:02 +0000 1 1 1 Unclassified XML Schema Structures: XSD Part 1 1.1 only PC All RESOLVED FIXED resolved P2 normal --- 1 cmsmcq David_E3 cmsmcq www-xml-schema-comments oldest_to_newest 44356 0 cmsmcq 2011-01-14 18:40:01 +0000 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). 46475 1 cmsmcq 2011-03-07 22:17:04 +0000 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). 46814 2 David_E3 2011-03-18 16:46:50 +0000 RESOLVED: adopt the proposal as presented. 46938 3 cmsmcq 2011-03-23 19:41:02 +0000 The decision reported in comment 2 has been implemented.