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 test 'Positive' of group 'valueconstraint00901m1' a fixed value constraint "alpha beta" of type "xs:anySimpleType" must be compared with the value "alpha beta" of an instance specified type definition "xs:string". See http://www.w3.org/TR/xmlschema11-1/#cvc-elt: 5.2.2.2.2 If E's ·governing type definition· is a Simple Type Definition or a Complex Type Definition with {content type}.{variety} = simple, then the ·actual value· of E is equal or identical to D.{value constraint}.{value}. But the datatypes spec says: "values from different primitive data spaces are made artificially unequal even if they might otherwise be considered equal". xs:anySimpleType is a special data type, xs:string a primitive data type. So in my opinion they can't have equal or identical values. But this is a little bit different for XSD 1.0 - see http://www.w3.org/TR/xmlschema-1/#cvc-elt: 5.2.2.2.2 If the {content type} of the ·actual type definition· is a simple type definition, then the ·actual value· of the item must match the canonical lexical representation of the {value constraint} value. So in my opinion the expected result must be invalid for XSD 1.1, and valid for XSD 1.0. Best regards, Andreas Meissl
(From Michael Sperberg-McQueen): We're not yet quite sure how to resolve this. Since anySimpleType is not a primitive but a special type, the rule quoted does not apply. The use of xsi:type may make a difference here, but so far the WG has not reached certainly on whether it does, or how. There is a rule in Structures 2.2.1.2 that says behavior of processors is unconstrained when validation rules implicate lexical mapping for types with undefined lexical mappings (like, for instance, the special types); that may mean that the behavior of 1.1 processors is unconstrained here, and the test case should be labeled accordingly.