RE: First pass at generated schema for DOM 1 + HTML

> [mb] Sorry, that's what I get for working without a net (the 
> DOM spec).
> Just glancing
> through, I've picked up the following where the spec says No 
> Return Value:
> 
> normalize, appendData, deleteData, insertData, replaceData, 
> setAttribute,
> setAttributeNS --


Those should not have a "var" attribute, if they do that is a production error.
In the handwritten schema, I had mistakenly used the "DOMFunction" type
when I should have used the "DOMSubroutine" type.  I believe I had corrected
that with the last handwritten schema and wrote a mea culpa.

In the generated schema, I may not have made the appropriate check and
reintroduced the problem.

I'm going to be travelling over the weekend, so tonight will be the last
I can work on this until next week.  I'll try to clean up as much as I can
and hand it over.

[mb] I'll have to look at particular tests to see what, if
anything, would come after this statement and what
the impact would be.

The reason that there is an <assertInstanceOf/> and no explicit casting
is that you can't depend on the language (specifically ECMAScript)
to preserve type-safety, so anytime that you really want to assert
that a particular variable is of a specific type is to use an 
<assertInstanceOf/> or use a method or property that is introduced by that type.

Since ECMAScript has no concept of casting, I thought it was easier
if the Java code generator just produced the appropriate cast operators.

<declare var="attr" type="Node"/>
<declare var="attrName" type="DOMString"/>
<name var="attrName" obj="attr" interface="Attr"/>

It would get produced to:

Node attr;
String attrName;
attrName = ((Attr) attr).getName();

or 

var attr;
var attrName;
attrName = attr.name;

Received on Thursday, 31 May 2001 18:31:25 UTC