SV: [Design] New proposal for DOM TS ML

I wasn't able to work as much as I thought today because of time pressure.
I'll send the updated DTD to the list together with the rest of the DTDs
tomorrow (Sunday). That is Document, DocumentFragment and DOM HTML.

We should be able to generate som instance documents (the important part)
fairly soon. Then we can bring the Schema and DTD together. 

/Dimitris

-----Ursprungligt meddelande-----
Från: Mary Brady [mailto:mbrady@nist.gov]
Skickat: den 26 maj 2001 21:41
Till: www-dom-ts@w3.org
Ämne: Re: [Design] New proposal for DOM TS ML



----- Original Message -----
From: "Curt Arnold" <carnold@houston.rr.com>
To: <www-dom-ts@w3.org>
Sent: Saturday, May 26, 2001 10:57 AM
Subject: Re: [Design] New proposal for DOM TS ML


> >[mb] It's not a matter of do I like the name or not -- Dimitris had
> indicated that
> >he would like to see as much reuse as possible, and I agree.  I have
raised
> the
> >inheritance issue several times -- the current proposal allows for
this --
> >quite honestly, I don't like having to specify  <Node><method ...></Node>
> >either, but I do like the reuse that this approach affords us.
>
> [ca] I'm all for reuse, but I like minimization better.  I tried to
respond
> to your inheritance issues
> in a couple of messages.  The only piece of information that I see that is
> necessary
> to have for code generation is the interface in which a method or property
> was
> introduced.  If you needed to distinguish between Comment.data and
> CharacterData.data
> to generate the code then the nested elements would be a good approach,
> but I forsee no need to do that (apart from the cast check which could be
> done
> as a distinct assertion).  I never had any intentions of adding, for
> example,
> <Element.nodeType/>, for example.
>

[mb] That's exactly my point.  I want to do things like Element.nodeType,
and
Comment.data.

> [ca] I actually was getting tired of using Node.getNodeName too.  Since
with
> the exception
> of the getElementByTagNames and code's, all property and method names are
> unique, the defining interface is unambiguous and doesn't need to be
> expressed
> in the test document.
>
> [mb] I have no preference -- I wasn't looking directly at your schema when
I
> started typing.  Maybe it should be returnVar -- so that it is not
confused
> with
> your next point.
>
> [ca]I like having the consistancy with <assign/> where returnVar would no
> feel right since there
> is nothing being called.
>

[mb] I don't know what you mean -- maybe the <assign/> statement in your
schema def?  Please expand on the problem with an example.

> [mb]  No, this was just an oversight.  Thanks for pointing it out.
> Initially, we tried to get away without this -- since most of the methods
> actually
> operate on the returnVar of the previous invocation, the transformation
> could do this for us.  Unfortunately, there are a few cases where you are
> not operating on the returnVar of the previous invocation -- so I agree,
it
> is much cleaner to put it in -- does everybody like obj, or should it be
> something else.  Maybe we could have the best of both, and put it in as
> optional -- if it is there, use it; otherwise use the returnVar of the
> previous invocation.
>
> [ca]I don't like the complexity that "temporary variables" would add to
the
> code
> generator or to the generated code.  You'd also have to be able to imply
the
> type of the temporary variable from the context and generate names for
> the temporary variable.
>

[mb] Yes, you do need to track the type, and in the original example, all
variables
were generated of the type var_Node, var_Element, etc -- tracking was not so
difficult -- if clarity is the issue, we can make the obj required.

Received on Saturday, 26 May 2001 17:29:58 UTC