Re: [Design] New proposal for DOM TS ML

Okay -- I've attached methods.dtd with all
Node definitions -- some things to note:

* defaulted DOMException to "NONE"
* In some cases, there is no return value, parameter, or DOMException.
   I'm leaving them off if I don't need them.
* In some cases, you may not have to assign a variable -- I'm thinking
   things like isSupported that return a boolean value -- in these cases,
   I propose that we assign variable to be #IMPLIED with a default of
   "NONE" instead of #REQUIRED.

I've also attached nodelist.dtd, namednodemap.dtd -- these only include
the necessary additions to the main dtd -- so that they may simply be
included.  I'm almost finished with characterdata and will continue on
for about another hour.  Will post what I have before I leave for the day.

--Mary

Mary Brady
NIST, Web Technologies
mbrady@nist.gov

----- Original Message -----
From: "Dimitris Dimitriadis" <dimitris.dimitriadis@improve.se>
To: <www-dom-ts@w3.org>
Sent: Friday, May 25, 2001 3:49 PM
Subject: [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>>
>