[Design] New proposal for DOM TS ML

Attached please find the new proposal for the DOM TS ML. It's been quickly
drawn up and is brought to the list to involve as many people as possible
from phase 1.

It's a tradeoff between the two previously proposed schemas and goes to show
that things can be merged. 

In the proposal, which has been deliberately left skinny, no reference to
the old <CALL/> is being made. Instead, IDL interfaces are defined directly
as well as IDL methods. Java-specific constructs have been deliberately
refrained from since we'd like to use as much DOM-specification specific
vocabulary as possible. It stays fairly close to Curt's proposal, the major
difference being that Node, for example, contains methods as elements
instead of defining Node.getNodeName as an element in its own right. I don't
think we miss anything crucial in doing this.

Curt, since you've thought hard about the construct mechanism, could you
look at that and incorporate it into this framework? Do it in DTD or Schema
form, whichever suits you, though I have to admit I personally prefer to
work in DTD first then export to Schema and take it from there. I'm
referring to the programmatical aspects, the if, whiles and so forth. Is
this a fair division of labour?

Mary is currently working on Node, I'm going to start on Document and
DocumentFragment tomorrow morning CET (it's 10 pm over here).

I think we can easily support <key> and <keyref> at a later stage in the
Schema version.

Concerning garbage collection: shouldn't this be left to the harness? I
don't know if the test _description_ is the right place to put it in. If I'm
wrong, we just include it.

Once we decide on the DTD/Schema, we can start converting existing tests and
XSLT documents as well as start work on updating wb resources and help
documents.

How does this sound as a starting point?

How much have I left out? Please add to the list of things to be done.

/Dimitris

 <<methods.dtd>>