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

new spec comments

From: Scott Ferguson <fergie@sirius.com>
Date: Sun, 26 Jul 1998 11:14:56 -0400 (EDT)
Message-ID: <35BA60F4.5B7DF39A@sirius.com>
To: www-dom@w3.org
Good work on the spec.  There's a lot to like in this version.
Still, there are a few things which might be improved :-)

* Shouldn't joinText have a single argument, i.e. 'joinText(in Text
node2)'?  The 'this' argument is node1.

* Is Attribute a Node just to reuse NamedNodeMap?  It's not really a big

deal, but using an Attribute in place of a Node can create bad
documents.  For example,

  attr = doc.createAttribute("foo");
  doc.appendChild(attr);

The implementation should at least be able to throw an exception but I
can't find an exception that would match this case and appendChild
doesn't throw an exception.

* I now understand why getAttributes() is in Node even though only
Element is likely to implement it.  But I'm most likely to use
getAttribute(name) and setAttribute(name, value).   So I'll end up
casting the Node to an Element anyway.  Maybe Node could expose the
latter two instead?

* The javascript bindings have a minor error: null argument functions
are given as properties instead of functions.

* The javascript might use some Bean-like design patterns, for a more
natural binding, e.g.

  elt.getAttribute("bgcolor"), elt.setAttribute("bgcolor", "puce"), and
elt.removeAttribute("bgcolor") can become

  elt.attribute.bgcolor
  elt.attribute.bgcolor = "puce";
  delete elt.attribute.bgcolor;

and elt.childNodes.item(3) might become elt.childNodes[3]

* Okay, naming is probably too much of a personal preference for me to
really suggest anything.  But it looks like some naming is still up in
the air, so I'll be arrogant and give my own preference.  :-) A more
consistent (and concise) naming scheme would be very cool.  For example,

I much prefer the jdk1.2 iterator to the jdk1.1 enumeration class, and I

know that I'll mess up the current DOM: "getParent, no for the DOM it's
getParentNode, and getNext, lessee for the DOM it's getNextNode, no it's

getNextElement, no getNextSibling.'

Document:
  createText
Node:
  getName, getValue
  getParent, getChildren, hasChildren, getFirstChild, getLastChild,
getPrevious, getNext
  insertBefore, replace, remove, add, clone
Element:
  getName (inherit from Node)
Node List:
  get, getSize
Data:
  substringData,appendData,insertData,removeData,replaceData
Text:
  split, join
(although, if Text and Data merged, so Comment and PI subclassed Text,
appendText, insertText, etc. would probably be better names.)

-- Scott
Received on Friday, 25 September 1998 11:10:05 GMT

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