[Bug 17252] New: [FO3.0] deep-equal() between typed and untyped nodes

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17252

           Summary: [FO3.0] deep-equal() between typed and untyped nodes
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Functions and Operators 3.0
        AssignedTo: mike@saxonica.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


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.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 30 May 2012 20:21:12 UTC