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>
Hi,

I encountered the following problems in the core specification:

- The NotMyChildException that is thrown in some Node operations doesn't
appear
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
are
added. In fact none of the two are necessary because we already have
CORBA::Object::is_a().

- It isn't specified where the iterator returned by Node.getChildNodes()
is
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
argument
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
it
throws a NoSuchException if the argument is greater that
NodeIterator.getLength().

- The TreeIterator interface isn't used anywhere. As it is a general
purpose
tree iterator it could be simply created on its own and initialized with
some
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
consistent.

- The explanation of getElementsByTagName in Document and Element says:
  "Returns an iterator through all subordinate Elements with a given tag
name."
  If I understand this, the iterator will see only a subset of the
subordinate
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
very
usefull anyway in my opinion.

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

- 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
original
node? Why isn't the inserted element not also just a sibling of the
original
node?

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'
Re BVBA
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 GMT

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