Re: [Design] New proposal for DOM TS ML

I've attached the following dtd components:

    CharacterData, Attr, Element, Text, Comment

Dimitris, you might want to take a look at how I was
able to inherit Node and CharacterData attributes
and methods -- in particular,

    Character, Attr, and Element inherit from Node
    Text, Comment inherit from CharacterData, which inherits from Node

If I get a chance, I'll move on to the extended interfaces -- I have not
done the following from fundamental:

        * DOMImplementation, Document, DocumentFragment

--Mary

Mary Brady
NIST, Web Technologies
mbrady@nist.gov

----- Original Message -----
From: "Mary Brady" <mbrady@nist.gov>
To: <www-dom-ts@w3.org>
Sent: Friday, May 25, 2001 4:40 PM
Subject: 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>>
> >
>