

Core HTML-compatible tests (was Re: Core HTML only tests)

From: Curt Arnold <carnold@houston.rr.com>
Date: Thu, 7 Mar 2002 22:51:58 -0600
Message-ID: <002001c1c65c$fb00d070$a800a8c0@CurtMicron>
To: "Mary Brady" <mbrady@nist.gov>, <www-dom-ts@w3.org>
Comments inlined:

----- Original Message -----
From: Mary Brady
To: www-dom-ts@w3.org
Sent: Thursday, March 07, 2002 11:10 AM
Subject: Core HTML only tests

Hi Everyone,

I'm about to start on trying to translate the level1 core xml
tests to be html only tests.

[ca] The new tests shouldn't be HTML-only, they should be HTML-compatible,
able to be run using XML, XHTML and HTML parsers.  We definitely don't want
to establish a set of tests that only run on HTML 4.

This will involve translating
staff.xml to an equivalent [X]HTML file, and modifying each
of the core tests to use this file, and manipulate the new
elements, attributes inside of this file.  Before I start, I
have a couple of questions:

1) Curt, could you possibly supply a skeleton with pointers
to how the tests should be set up?  In particular, should I
do anything inside the test to indicate that the test is for
HTML only implementations?  What about any pointers
regarding case-sensitive, case-insensitive comparisons?
I know this has been discussed, but I don't remember
the resolution.

[ca] The tests shouldn't need any (additional) guards since they will not
on the HTML DOM interfaces.  I'll take a quick shot at adding the validation
guards to the existing tests to address the default attribute issue.

[ca] When doing an assertion on a returned tag name or attribute name,
you should use a lower cased expected value and ignoreCase="auto"
which will do a case-insensitive comparison for XML and XHTML documents
and compares the returned value with an uppercased version of the expected
for HTML.  Arguments to getElementsByTagName should be lower-case.

2)  Where should I put the tests? Under tests/level1/core -
should we mix them with the available xml tests or create
a separate directory?

[ca] They should be in the same directory, they just are a parallel set
of tests for the DOM L1 core, just a set that is also compatible with
HTML parsers.

3) What about naming -- my gut feeling is that the tests will
be similar in concept to the xml equivalent, but may be
significantly different in terms of what tags we grab, etc.
Any feelings on whether we should keep the nameHTML,
or possibly name them as we did for level2 tests, or
any other suggestions?

[ca] It might be good to avoid calling the HTML since that might imply
that they were HTML-only.  Maybe hc_existingtestname (hc_ for

Here is the process that I would suggest:

1. Create hc_staff.xml, hc_staff.dtd, nodtd_staff.xml from the existing
staff* files by a one-to-one mapping of HTML names for the existing tag and
attribute names, replacing <staff> with <html><body> and adding the XHTML
namespace and DTD.

I think the minimalistic approach where the staff.xml and hc_staff.xml and
nearly structurally identical will be much more effective than trying to
make create a hc_staff.html that looks like a report generated from

2. Create an hc_staff.html from hc_staff.xml.  Run it through HTML
validation to make sure that it is legal HTML.

3. Copy existing test definitions to make hc_*.xml test definitions.  Do
global search and replaces to substitute "a" for "address", etc.

4. Iterate on tests until both existing and new tests give comparable
results with Xerces and other high-compliance XML parsers.

5. Review <assertEquals> to set appropriate assertions (only a small
fraction) to ignoreCase="false"

6. Iterate with HTML implementations
Received on Thursday, 7 March 2002 23:52:02 GMT
