More comments

o It's unfortunate that attributes is an attribute of Node when it is
null for all subclasses except Element.  I suppose this was to avoid
having to cast an Element object that is gotten from a NodeList :-(
(Even if there is an attributes in future Declaration subtypes, I don't
really think it belongs in the base interface.)

o Why "nodeName", "nodeValue", "nodeType" attributes of Node and not
just name, value, type?  All Node subclasses have a attribute that could
reasonably be refered to as "name" and many have a "value".
Programmers can make use of the convenience methods with signatures like
Element.getTagName() and ProcessingInstruction.getTarget() to access the
name variable with more semantic if they want to.

That brings up what I believe is a typo in the ECMA script interface. 
It states that Object Attribute has all the properties and methods of
Node as well as the properties defined below, and "name" is defined
below.  This suggests that Attribute has both the property nodeName and
name.  I don't think scripts can alias two variable names for a single
variable in its object model, or are there supposed to be two different
variables? (Same thing for Element, etc.)

o You specify that the NodeList returned by Node.childNodes() must be
live.  Is this true of all NodeLists?  What about NamedNodeMaps, is it
required that they are static (I ask because they allow enumeration)?

o What were the objections to having a single NodeList interface
providing both an an index accessor and a name accessor (and not have
NamedNodeMap)? 
It's my understanding that all Nodes in the DOM will normally have a
non-null name, so all collection types should be able to handle name
access (however inefficiently).  Of course smart implementations should
use appropriate collection types for the various collections based on
"liveness" and ordering requirements and predicted use patterns, but it
seems they could all use the same NodeList interface.

o I am trying to understand the exceptions in Data.  
The "data" attribute specifies that "If the character data of node
cannot fit into the length of a wstring a DOM exception is raised." 
Does this mean that append, insert, and replace raise this exception
even though they don't say they do?  The comment seems to suggest that
the exception is raised during a property setter operation.  If so,
isn't the character data already in a wstring before assignment?  What
does the following statement mean, "If this exception is raised, the
user may call substring to retrieve the data in manageable chunks"?  I
don't understand where the character data was put such that it is now
accessible via this object's substring.

Then in the substring method, "a DOMException is thrown if the specified
range of text will not fit in a wstring."  How could a substring of a
wstring not fit in a wstring?  Is substring() capable of pulling data
from adjacent or child Text nodes?  That's the only way I could think of
getting this exception.  Also, shouldn't substring thow an invalid
offset exception?


Cheers.
ted

Received on Thursday, 23 July 1998 15:25:17 UTC