W3C home > Mailing lists > Public > www-dom@w3.org > July to September 1998

Re: More comments

From: Mike Champion <mcc@arbortext.com>
Date: Thu, 23 Jul 1998 16:09:25 -0400
Message-Id: <98Jul23.170256edt.26925@thicket.arbortext.com>
To: Ted Bashor <bashor@crossroute.com>, www-dom@w3.org
At 03:28 PM 7/23/98 -0400, Ted Bashor wrote:
>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.)

You're right as to why this was added; we had to come to grips with the
fact that "casting" is fairly expensive in Java and COM, and some wish to
use the DOM in performance-critical environments. So, we allow full
functionality using just the Node interface, but still support the
higher-level interfaces for those who prefer a more object-oriented API. 

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

ECMAScript in particular is rather limited in its name scoping rules, and
"simple" names will tend to clash with legacy APIs, so we have used the
naming convention of using the interface name in the methods to minimize
the chances for name clashes.

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

That will be fixed in the next release.

>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)?

We'll apparently have to clarify this in the spec.  As I understand it,
NamedNodeMaps are static (which is why they're not derived from NodeList).  

>o What were the objections to having a single NodeList interface
>providing both an an index accessor and a name accessor (and not have

There was much feeling in and outside of the WG that this would confuse
more people than it enlightened. 

>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?  

Hmmmm ... they SHOULD say they do ... I'll double-check and fix if necessary.

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.

The scenario here is to imagine that a DOM document has some Data object
that is larger than the size of a wstring on some platform (it presumably
would not be stored internally using the data type that wstring maps
onto!).  We added a means of telling the user that extracting the entire
Data object would cause an overflow, and give them a means of extracting
the Data in manageable chunks.

>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? 

Could you point to something in the text that gives you the impression that
the value of a Data object is a wstring (as opposed to an arbitrarily large
collection of character data)?  We need to dispel that misconception.


Mike Champion
Received on Thursday, 23 July 1998 17:06:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:04 UTC