W3C home > Mailing lists > Public > www-dom@w3.org > October to December 1997

Comments from implementing java dom classes.

From: Alexandre Rafalovitch <arafalov@socs.uts.EDU.AU>
Date: Fri, 17 Oct 1997 21:44:03 +1000 (EST)
To: www-dom@w3.org
Message-ID: <Pine.SOL.3.95.971017211733.6388C-100000@charlie>
NoSuchNodeException extends Exception. The alternative is for it to
extends RuntimeException. In the current case it has to be cought by
everybody calling methods even if they know there would be no problem. (as
Also, currently in java binding there is only default constructor and 
no constructor that takes a string. It would be nice to have one, to
provide some feedback on why exception was thrown and not only where.


in item(0) when items is not null. In the second case, it can propogate
without declaration in the same way IndexOutOfBoundaries exception
propogates for array access. (you don't want to put try and catch on every
a[i]=j... :-}

In Node: getFirstChild() is missing in java interface files.
In NodeList: 
   prepend description refers to insertChild - should be insert.
   replace() method is declared as returning void, should be Node.
   Description for replace has following text:
     (null is returned if the index is equal to the previous number
	 of nodes in the list).
   What is this _previous_ number of nodes refer to? 

Questions on logic:
In Node:
  getPreviousSibling, getNextSibling are traversing in breadth first 
  order. Does it mean the getNextSibling on the last element _in a 
  level_ would go to the first child of the first element of that 
  level? That is the way I understood breadth-first traversal. 
  I would have imagined that it would stop once it reaches last element
  of the level it is currently on. (level defined by a common parent).
  For example:
  x1
  |-x2.1
  | |-x3.1
  |
  |-x2.2
  |
  |-x2.3

  Would getNextSibling on x2.3 go to x3.1? It would for proper 
  breadth first traversal.


  getElementsByTagName is depth first. Is it prefix, postfix, infix or
  leaves only order? 

In general, it seems that having setters for some of the attributes
does not make sense (they are derived) and they should be read only.
For example: setSpecified on Attribute does not make sense as it is
 an indication of whether value was supplied with setValue() or not.
 Same with setCharacter for NumericCharacterReference and several
 others.


Regards,
  Alex.
Received on Friday, 17 October 1997 07:44:24 GMT

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