Making DOM L3 tests compatible with XHTML and SVG implementations

Ancient history follows:  The initial NIST tests that were donated to 
this effort used test files with elements such as <staff/> and 
<employee/>.  Unfortunately, these tests could not be used with HTML and 
XHTML implementations since they would reject documents that were not 
valid HTML or XHTML.  To leverage the existing tests to test Core 
behavior in [X]HTML implementations, the existing data files such as 
staff.xml were transformed to valid [X]HTML by substituting HTML tag 
names with compatible content models and corresponding changes were made 
in the tests.  For example, <employee> was replaced by <p> and <address> 
by <acronym>.  The HTML-compatible variants were identified by an hc_ 
prefix, such as hc_staff.xml or hc_characterdatagetlength.xml.

The L3 Core tests used variants of the L2 Core staffNS.xml data file.  
Unfortunately, that made the tests inapplicable to XHTML 
implementations.   I've just reworked the L3 Core tests to use a variant 
of hc_staff.xml and a series of much simpler files for encoding and XML 
declarations tests and committed the changes as bug 455.

A series of global replacements were performed on the original tests, 
then an iterative process of making changes and comparing the results of 
the new tests and old tests using Xerces CVS was performed.  With a 
handful of exceptions (discussed below), the transformed tests have 
consistent results with the old tests.  There is the chance that the 
testing objective of a few tests were compromised without a discernable 
change in results.

Tests with changed results:

entitygeinputencoding03, 04, entitygetxmlencoding03, 04, 
entitygetxmlversion03, 04:

These tests were rewritten using newly created test files and Xerces now 
passes them all where it previously failed them all.  The previous tests 
might have been flawed, but I will need to investigate.

nodecomparedocumentposition39 and 40:

These tests compared the position of two attributes on the same element 
and expected the order to be IMPLEMENTATION_DEPENDENT and PRECEEDING.  
However, if the order is really implementation dependent, you could not 
make an assertion that it should be PRECEEDING.  I introduced an 
optional bitmask attribute for assertEquals, assertNotEquals, equals and 
notEquals that results in a bitwise AND of both the actual and expected 
values to be performed before the comparsion.  The tests now check that 
IMPLEMENTATION_DEPENDENT is set, that PRECEEDING or FOLLOWING is set and 
that no other defined bits are set.  The Xerces implementation passes 
that much, but on an additional assertion that I made that if (attr1, 
attr2) is PRECEEDING then (attr2, attr1) had to be FOLLOWING,

nodegettextcontent14:

This test compares the textContent value for hc_staff against an 
expected value.  The new test fails due to an apparent change in 
new-line characters.  I will need to investigate this test further.

nodegettextcontent18:

This test compares the text content of entity node.  The entity node has 
changed between the test documents and the implementation does not 
return the value that I expected.  I believe this uncovered a bug not 
exposed by the original test.

Received on Monday, 5 January 2004 03:32:51 UTC