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

Re: More comments

From: Stephen R. Savitzky <steve@crc.ricoh.com>
Date: 23 Jul 1998 15:07:52 -0700
To: Mike Champion <mcc@arbortext.com>
Cc: www-dom@w3.org
Message-ID: <qck954b4qv.fsf@gelion.crc.ricoh.com>
Mike Champion <mcc@arbortext.com> writes:

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

I would like to strongly suggest that "value" should return a NodeList, and
"data" should return a wstring (which is the way things were a couple of
revs ago).

This makes the decision of whether to represent attribute and entity values
as children an implementation decision, and allows values (which might be
quite large in the case of entities) to be shared.

It also makes a lot more sense to call the string associated with a Text
node its "data" than to call it its "value".

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

Would it avoid these conflicts by defining getName, getValue, setName, and
setValue as methods instead of making them attributes?

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

It sounds to me as if you may need two kinds of NodeList, one that's
``live'' and one that isn't.  You need _something_ to return as the value of
an operation that returns multiple nodes from different places in a
document.  I suspect this may have been the original motivation behind
DocumentFragment, but to use it you would have to move the nodes out of their
original places in the document, which misses the point.

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

If this is the case, you probably have to define getData and setData as
separate methods rather than defining data as an attribute.

-- 
 Stephen R. Savitzky   Chief Software Scientist, Ricoh Silicon Valley, Inc., 
<steve@rsv.ricoh.com>                            California Research Center
 voice: 650.496.5710   fax: 650.854.8740    URL: http://rsv.ricoh.com/~steve/
  home: <steve@starport.com> URL: http://www.starport.com/people/steve/
Received on Thursday, 23 July 1998 18:03:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:45 GMT