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.

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

> > 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 17:45:30 UTC