Re: Issues brought up in the DOM WG and general principles for the future

> Given that ECMA is not a language that does not support exceptions, a
> system that is built with ECMA support and does not support exceptions
> cannot be considered conformant to the DOM. If a system does not use
> ECMA and therefore not exceptions, it is a non-issue for the DOM WG.
> Thus, the DOM TS framework will be rewritten and the workaraound must be
> removed.

Changed in DOMTestCase.js rev 1.14.
DocumentBuilder.isDOMExceptionCode(ex,code) now returns (ex.code == code).
This results in every test where an expection is anticipated to fail for all
COM-based implementations accessed from JScript.

> Default attributes: According to the DOM level 1 specification, it's not
> an error no to load default attributes. Later versions of the DOM
> require the explicit loading of default attributes. So, not loading
> default attributes should raise a warning, not an error.

If a test's expected behavior is deemed to not be required by DOM L1 Core
but to be required by DOM L1 Core, then the test should be removed from the
DOM L1 Core test suite (that is removed from alltests.xml) and added to the
DOM L2 Core test suite.

It would be good if DOM L3 could be extremely clear on the conditions, if
any, that a conformant processor could not provide attribute nodes for
default values.

However, I'm not sure what the magic phrase that makes providing default
attributes required in DOM L2 and optional in DOM L1+Errata.

For example:
http://www.w3.org/DOM/updates/REC-DOM-Level-1-19981001-errata.html (Section
1.2 Interface Document)

The description of the createElement method is missing the following piece:
  In addition, if there are known attributes with default values, Attr nodes
representing them are automatically created and attached to the element.
This errata seems to make L1 behavior identical to L2 behavior (at least for
createElement).  If you want to make adding the default attributes optional,
then you have to start fine-tuning the the interpretation of "known".
Definitely in these tests default attribute values are specified.  They
should be "known" if the parser was validating since reading the external
subset would be required.  Would they be specified but not truly "known" by
the processor when non-validating and the definitions were in an external
subset?  How about when they were in the internal subset?

Marking the default attribute tests as requiring a validating parser would
probably be the best resolution for the default attribute tests.  Unless
there are objections, I can guard these tests so they only run if validation
can be enabled.

Quite a few tests failed in Mozilla because of the total lack of a
DocumentType node.  Is there a scenario under which this is conformant?

>General reports: I did have a series of meetings with representatives
>from Microsoft and Netscape, mainly, where they indicated interest in
>our work and promised to help out as much as possible. Specifically:

>Netscape reiterated their commitment to help out on the framework, which
>we have seen in Bob's interest. I look forward both to resources and of
>course the tests we were promised.

It would be nice if Netscape could make their tests incrementally visible.
I know NIST was relunctant to do so, but it really makes things easier to
see things as they are evolving instead of having to fix up 400 tests at a
time.

>Microsoft wants a less discriminating loading mechanism of tests (I
>spoke to a representative of the IE for Mac group), and indicated that
>they will look into this and help out. One idea was to use DOM "level 0"
>for document loading to allow for testing of more than the currently
>supported browsers. Given Jason's previous work I feel certain we'll
>manage to run the tests smoothly in IE for both these platforms. I look
>forward to a submission of ideas and code.

HTML documents are loaded through DOM L0 type mechanisms (window.open).  I'm
still totally in the dark on how you would load an XML document on Mac IE.

>DOM WG: I (again) raised the issue of having to get more tests submitted
>from member companies, especially as we want to move along as a WG to
>reach Recommendation of DOM level 3. The DOM WG members promised to look
>into this and try to allocate resources. I also brought the issue that
>there have been very limited resources working on the DOM TS to the DOM
>WG's attention, indicating that this cannot continue indefinitely if we
>want to ensure some sound quality requirements for the DOM TS.

Making any existing tests (in whatever language) available would be a great
help.

Received on Saturday, 2 March 2002 17:53:05 UTC