This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The specification of deep-equal() has always stated that type annotations are ignored when comparing elements; however if one element has a complex type and the other a simple type, then they are not deep equal. (The spec doesn't say this very elegantly: its words are "The two nodes are both annotated as having simple content or both nodes are annotated as having complex content.") (It actually goes beyond this, two nodes that both have complex type but with different variety, e.g. one mixed and one element-only, cannot be deep-equal) There has never until now been a test for this in the test suite, but I have now added one: K2-SeqDeepEqualFunc-39. I have also changed my product to pass this test. This has an unforeseen and in my view undesirable consequence: as a result of making this change, an untyped (unvalidated) document is no longer deep-equal to its validated equivalent, if the validated tree has any elements with simple content. I discovered this very quickly because my test driver uses deep-equal() for comparing results - in fact, there may well be tests where we incorrectly make a deep-equal assertion. I am raising this bug to invite discussion on whether we should consider changing the specification in this area. It would be interesting to know how other implementations handle this test case. I have raised the bug against 3.0, but making a change here would be an incompatibility with the 2.0 specification, which we could only justify if the overwhelming majority of implementations have failed to enforce this rule correctly. One possible solution, short of removing the rule entirely, would be to say that if one of the nodes is untyped, the other is treated as untyped for comparison purposes.
If we decide to leave the spec technically as is, I propose to make editorial clarifications as follows: (1) change 3(b) from "The two nodes are both annotated as having simple content or both nodes are annotated as having complex content." to "Either both nodes are annotated as having simple content or both nodes are annotated as having complex content. For this purpose "simple content" means either a simple type or a complex type with simple content; complex content means a complex type whose variety is mixed, element-only, or empty." (2) change the sub-bullets of 3(d) to read: * Both element nodes are annotated as having simple content (as defined in 3(b) above), and the typed value of $i1 is deep-equal to the typed value of $i2. * Both element nodes have a type annotation that is a complex type with variety element-only, and each child element of $i1 is deep-equal to the corresponding child element of $i2. * Both element nodes have a type annotation that is a complex type with variety mixed, and the sequence $i1/(*|text()) is deep-equal to the sequence $i2/(*|text()). * Both element nodes have a type annotation that is a complex type with variety empty. I'm not sure if we also need to clarify what "corresponding" means in the second bullet. One might argue that if the content model uses "any" rather than "sequence" then the correspondence should be by name rather than by position.
Accepted the changes in comment #1 (editorial changes only)