Re: [Design] New proposal for DOM TS ML

----- Original Message -----
From: "Arnold, Curt" <Curt.Arnold@hyprotech.com>
To: <www-dom-ts@w3.org>
Sent: Friday, May 25, 2001 5:44 PM
Subject: RE: [Design] New proposal for DOM TS ML


> I'm probably not going to have a chance to look at this even superficially
until mid-day on Saturday CDT.
>
> In my stuff, if a parameter could be null, I made it optional.
>
> I had made a variable for a return value a required attribute since I
think it would be rare (maybe 5%) that you would have no need for it and it
doesn't hurt in those few cases to define a dummy
> variable for it.  Having it required makes it easier for the vast majority
of cases since a schema or DTD aware editor will construct the attribute for
you.  If it is optional, it requires more
> editing effort.

[mb] In some cases, there are no defined return values, parameters, etc --
since in this go-round, we have an element for each method/attribute,
we can be disciminate in what is defined -- this is consistent with the DOM
spec.  In the interfaces that I've been through, it happens much more
so than you might think -- just scan the IDL def's for anything of type
void -- having the correct info available to the transformation makes
for cleaner generated code -- if that's possible :-).

>
> Using <Node><nodeName var="a"/></Node> loses the ability to constrain
using DTD when the same method or property name appears in multiple contexts
with different calling signatures.  Off the top of my
> head, then only name conflicts that I can think of is getElementByTagName
which occurs both in document and element, but with a consistent signature.
If you don't like <Node.nodeName/>, I'd prefer
> just <nodeName/> and I can embed into the schema the interfaces that it
applies to and try to decide which is appropriate, however that does
increase the complexity of the transform.  Maybe in cases
> where the same function appears in multiple contexts, we could still
disambiguate it, so there would be a <Document.getElementsByTagName/> and a
<Element.getElementsByTagName/> but everything else
> would be just <nodeName/>.
>

[mb] If you account for inheritance, the same method /property names should
occur in lots of places.

--Mary

Mary Brady
NIST, Web Technologies
mbrady@nist.gov

> > > 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.
>
> The intention of <garbageCollect> was for cases when it is thought that
the test results might be influenced (in a negative way) by garbage
collection.  The specific test that I used it in created an
> event, initialized it, released it (assuming that it went back to an event
pool either immediately or on some garbage collection) and created a new
event and dispatched it.  The idea was that a bad
> event pool implementation might not have cleared the state when the
original event was recycled and would not throw the expected exception.
>
> That was the intent, but that is such a fringe thing to test for, that it
is probably not worthwhile to have it in there since there are probably no
platforms that have garbage collection but also
> allow you to implement your own object pooling.
>
>

Received on Friday, 25 May 2001 18:28:19 UTC