W3C home > Mailing lists > Public > www-dom@w3.org > April to June 1998

Core specification

From: Werner Donne' <wdonne@ibm.net>
Date: Wed, 08 Apr 1998 17:47:59 +0200
Message-Id: <352B9C2F.3C265C2B@ibm.net>
To: dom <www-dom@w3.org>

I encountered the following problems in the core specification:

- The NotMyChildException that is thrown in some Node operations doesn't
in the Node interface definition.

- The explanation of the operation Node.getNodeType() says an enum is
used to
indicate the type while that is not true anymore. By the way, it is
better to
use constants instead of enums because code would break when new types
added. In fact none of the two are necessary because we already have

- It isn't specified where the iterator returned by Node.getChildNodes()
positioned, i.e. at the first node or before the first one. Both
policies can
be encountered in public libraries. For the moment I assume it is
positioned at
the first node.

- NodeIterator.toNth() should also return NoSuchNodeException if the
is negative because the argument type is not unsigned.

- NodeIterator.toNth() is inconsistent. It says it returns null if the
iteration leads to a position beyond the end of the list. It also says
throws a NoSuchException if the argument is greater that

- The TreeIterator interface isn't used anywhere. As it is a general
tree iterator it could be simply created on its own and initialized with
Node from where navigaton should start. The following should then be
added in
the Document interface:
  TreeIterator createTreeIterator(in Node startPoint);

- I see no reason why Document should be derived from DocumentFragment.

- Element.attributes should be called Element.getAttributes to be

- The explanation of getElementsByTagName in Document and Element says:
  "Returns an iterator through all subordinate Elements with a given tag
  If I understand this, the iterator will see only a subset of the
elements selected with a tag name. In that case there should be an
argument. It
could also mean that all subordinate elements are returned ordered by
the tag
name. In that case the explanation is not correct. This meaning is not
usefull anyway in my opinion.

- Everything in the XML specification that has to do with the document
definition, ie almost the whole of it, should be in Core because it is
to XML and HTML. In HTML a number of operations will return empty lists
course. Note that the Attribute interface refers to document type

- I think Element.attributes should be Element.getAttributes.

- Is Element.normalize recursive?

- The sentence below Text.delete is wrong.

- The explanation of Text.splice is quite obscure. What happens to the
node? Why isn't the inserted element not also just a sibling of the

A general comment:
  It would be nice if the types of the arguments were included in the
specifications of the individual operations.

With kind regards,

Werner Donne'
Leuvenselaan 172
B-3300 Tienen
tel: (+32) 16 810203
fax: (+32) 16 820826
E-mail: wdonne@ibm.net
Received on Wednesday, 8 April 1998 12:37:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:26 UTC