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