Re: Issues about the DOM TS brought up in the DOM WG Telcon

Sorry, I've got a volume to deal with, but let me have a quick go at the 
simple answer.

Curt Arnold wrote:

>>1. Browser sniffing -- it seems that the sniffing is not elaborate
>>enough, makes Mozille, for example, run code with calls to an ActiveX
>>object.
>>
>
>I'll admit that it isn't elaborate, but under what scenario does Mozilla run
>an ActiveX object?
>
When the TS identifies it as IE and tells it to load Active X components.

>>2. Tests on default attributes require a validating parser, which is not
>>a requirement (for XML)
>>
>
>It doesn't require that the document be validated, but it does require that
>the DTD be processed.  The DOM rec doesn't seem to allow a processor to omit
>default attributes or return null for doctype when there is a DTD.
>
The DOM spec only requires that which is required by XML of a 
non-validating processor.  A non-validating processor is not required to 
read the DTD.  It is only required to read and be aware of default 
attributes in the very unlikely scenario that they are declared in the 
internal subset, and then I believe there are some rules that let it 
ignore them starting at some points such as an external parameter entity 
reference where something will be missing.  If there are tests, they 
should be clearly labeled as for default attributes in internal subsets 
-- which are seldom used.

>, for HTML default attributes need to be there.
>
>>The issue is then that the TS tests the XML appclication DOM, not the
>>browser DOM
>>
>
>The DOM Level 1 test suite currently only contains tests for XML and SVG
>documents.  Microsoft IE does not have an browser implementation of the XML
>DOM so the MSXML2.DOMDocument is used for tests using XML documents.  Since
>Mozilla does have a XML DOM in the browser, it is used for tests on XML
>documents.  I believe that Netscape was converting going to be providing DOM
>1 Core tests that use HTML documents, and when those tests are run using
>HTML documents they will use the browsers HTML DOM implementation.
>
As people will compare the results, there has to be clarity about what 
was tested.  I believe each implementation must clearly list what it did 
and did not pass.  If one set of results are given as though they are 
for the same implementation, and two implementations are being used to 
satisfy the requirements, that seems wrong.  If IE has two 
implementations, then there are two sets of results.  If the test suite 
is broken into modules so that you can say "not tested" for one of the 
modules, that seems appropriate, because it, too, clearly shows that 
individually the implementations do less.

My 2 cents, anyway.

Ray Whitmer
rayw@netscape.com