SV: [Design] New proposal for DOM TS ML

Comments inlined below

-----Ursprungligt meddelande-----
Från: Arnold, Curt [mailto:Curt.Arnold@hyprotech.com]
Skickat: den 25 maj 2001 23:45
Till: 'www-dom-ts@w3.org'
Ämne: 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.

[dd] As an entry helper, it sounds good. We don't want to scare people away
from writing tests because it's tood difficult. However, I expect people to
be familiar enough with DOM to know about differences as far as variables
are concerned. If we see that this is wrong, this needs to be changed.

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/>.

[dd] I think we can easily disambiguate this in the scema version. I for one
know that the schema will be more complex and heloful, but I think
developing in DTD form right now is easeier and faster. In any case, we'll
end up with a schema and a DTD, and the natural shortcoming of DTD will be
obvious.

> > 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 Saturday, 26 May 2001 11:07:50 UTC