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

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

From: Dimitris Dimitriadis <dimitris@ontologicon.com>
Date: Sat, 2 Mar 2002 17:02:13 +0100
Cc: bclary@netscape.com, jasonbri@microsoft.com, tantekc@microsoft.com
To: www-dom-ts@w3.org
Message-Id: <DC4C55F0-2DF6-11D6-8E78-000393556882@ontologicon.com>
Let me briefly report back on the issues I brought to the DOM WG for 
resolution:

---

NO_MODIFICATION_ALLOWED_ERROR issue not resolved yet. We discussed it 
and will have a resolution in one of the near future telephone 
conferences.

---

Browser sniffing, bootstrapping, asynchronous loading of document and so 
forth: as these issues were brought up by Netscape, we agreed that they 
be resolved in the DOM TS group work.

---

Exception handling: The DOM WG resolution is this: The DOM is defined 
for ECMA, which supports exceptions. Therefore, any DOM implementation 
for ECMA script should support this feature. The previously sent email 
to this list by Jason Brittsan contained the following (I'm currently in 
a plane and cannot look up the archives):

Comments regarding DOMExceptions:

http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/level-one-core.html#ID
-17189187

<quote>
Some languages and object systems do not support the concept of
exceptions. For such systems, error conditions may be indicated using
native error reporting mechanisms. For some bindings, for example,
methods may return error codes similar to those listed in the
corresponding method descriptions.
</quote>

By returning error codes, Internet Explorer does conform to the DOM
Level 1 specification.

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.

---

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.

---

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 11:01:49 GMT

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