4063 2006-12-10 00:18:14 +0000 IdentityConstraint test idZ015: anySimpleType 2008-11-11 16:40:45 +0000 1 1 1 Unclassified XML Schema Test Suite Microsoft tests 2006-11-06 PC Windows XP RESOLVED INVALID metadata update confirmed 2008-11-11 P2 normal --- 1 mike ht public-xml-schema-testsuite oldest_to_newest 13124 0 mike 2006-12-10 00:18:14 +0000 In the Microsoft IdentityConstraint test set, test idZ015, the value of the field selector is a node that (as a result of matching an anyAttribute wildcard) has type xs:anySimpleType. The author of the test appears to have concluded that the instance document is therefore invalid. I don't see how this can be inferred from the spec. The spec says that every datatype (presumably including xs:anySimpleType) has a value space, and has an equals() operator; the semantics of the equals() operator in this case are not clearly spelt out, but this test could only fail if the equality relation were undefined, which it isn't. Unless I've missed a rule that the test author is relying on, the WG needs to provide clarification of this case. 13768 1 zafara 2007-01-22 22:10:18 +0000 This test is marked invalid for the exact reason that the behavior of equals() is undefined in the case of xs:anySimpleType, instead of making a guess and going with it, it was considered best by the Microsoft interpretation of the spec and its implementation to error in this case. 20726 2 mike 2008-06-22 14:29:50 +0000 In 1.0 we can argue that because the attribute is skipped, it has no type, therefore it does not "have a simple type", therefore it is invalid. (Assuming this phrase means "has a governing type definition that is a simple type".) Added a comment to bug #5780 which affects the same text in the spec. Noted that in 1.1 the definition "Call the sequence of the [schema actual value]s of the element and/or attribute information items in those node-sets in order the key-sequence of the node." is less than clear. (a) "those node-sets" are actually node sequences, and (b) the idea is that they DONT include the skipped nodes. So in 1.1 the target node-set contains the foo element, this node-set contains a node for which the XPath expression selects no (unskipped) nodes, and this makes the qualified node-set empty. Another 1.1 concern here is the term "skipped", which means "attributed to a skip wildcard". Can we determine this from PSVI properties? Answer: yes, the PSVI property "attribute attribution" tells us. Under both definitions we have come to the conclusion that the instance is indeed invalid. Therefore no change to the test suite is required (except that a comment referring to this explanation would be helpful!)