W3C home > Mailing lists > Public > www-dom-ts@w3.org > March 2002

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

From: Curt Arnold <carnold@houston.rr.com>
Date: Sat, 2 Mar 2002 16:52:45 -0600
Message-ID: <001801c1c23c$fa518f80$a800a8c0@CurtMicron>
To: <www-dom-ts@w3.org>, "Dimitris Dimitriadis" <dimitris@ontologicon.com>
Cc: <bclary@netscape.com>, <jasonbri@microsoft.com>, <tantekc@microsoft.com>
Dimitris Dimitriadis wrote:
> 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 conformance test suite (that is removed from alltests.xml) and
added to the DOM L2 Core conformance test suite.  We also could create an
nonnormative test suite for tests failure of which is undesirable but would
not constitute a non-conformance.

However, I'm not sure what the magic phrase that makes providing default
attributes required in DOM L2 and optional in DOM L1+Errata.  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.

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

>
> ---
>
> 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.
>
> 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.
>
> 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.
>
> W3C:
>
> Let's draw some experiences from the work done so far:
>
> I'm still personally very pleased to see that we not only managed to
> work together in a pleasant way, but especially that we produced
> something which we can all be happy with (it is of course subject to
> improvement). However, I want to flag for a few things I've observed:
>
> As a general principle, the companies interested in the DOM TS must
> allocate resources to the DOM TS group for solving specific issues (eg.
> loading, framework, assuring test quality, test submission and so forth)
> as it is in their immediate interest. As the coordinator of this effort
> I don't want to see any more drainage of individuals to solve platform
> and implementation specific problems (or framework issues for that
> matter), especially if representatives for those platforms and
> implementations do not allocate resources to aid in solving issues. We
> are all working in good faith and a spirit of cooperation, and I want
> this to be reflected in the resource allocation. Especially considering
> the obvious value a sound and thourough DOM TS has for implementors, I
> look forward to having a broader group than the current one working on
> future version of the DOM TS.
>
> The framework is now up and running, and there is a clear communication
> channel for submitting tests and discussing framework issues. Given that
> the release two weeks ago was our first one, I understand that issues
> were raised and now (hopefully) solved, and I look forward to discussing
> more issues and taking them to the DOM WG for resolving as they are
> raised.
>
> However, we need to steer clear of pitfalls in order to ensure that we
> release at regular intervals and with a decent coverage.
>
> One such pitfall, as I've indicated, is more tests. We already see some
> good intentions in this area, and I look forward to receving more
> submissions from organizations other than the ones who launched the DOM
> TS activity.
>
> Another pitfall is that we cannot ensure that the framework run on every
> single platform if we don't have enough feedback and resources from the
> platform's organization. It goes without saying that if the only option
> we have is to use a generic simple framework, it will be quite difficult
> for any given implementation to endorse any claim on conformance with
> the DOM Specification if the framework does not run a for that
> implementation and its representatives have not aided in ensuring that
> the particular implementation support the framework.
>
> If what needs to be done in order to avoid this is more frequent builds
> for testing the DOM TS so that members of the DOM TS group can gain
> insight, this is what we'll do. If there is anything else we can to do
> comment and constructively criticise the DOM TS, please advise (such as
> better documentation, better reporting from me, etc.).
>
> I'll get back to the list with a more detailed agenda of action items
> that need to be dealt with, and I'll propose a divison of labour which
> I'll be happy to discuss. In the meantime, I very much look forward to
> your comments on what I say above and again stress that we all have the
> best of intentions in this effort.
>
> Best,
>
> /Dimitris
>
Received on Saturday, 2 March 2002 17:53:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 April 2009 12:58:46 GMT