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

core::Node and inheritance

From: (wrong string) <wdonne@ibm.net>
Date: Thu, 09 Apr 1998 17:19:46 +0200
Message-ID: <352CE712.E58@ibm.net>
To: DOM <www-dom@w3.org>

A few remarks about core::Node and inheritance:

- There is another problem with the constants defined in core::Node to
the subinterfaces of Node. For interfaces outside of core there aren't
constants. However, classes implementing these interfaces must provide
something for Node.getNodeType. This means there must be a public
somewhere to compare the result with. For the xml module these could be
put in
XMLNode. Then XMLNode must also inherit from core::Node and all
interfaces in
xml that now inherit from core::Node must inherit from XMLNode.
I still think dropping the constants is best but a compromise could be
to spread
them over all interfaces that inherit from core::Node. This way you can
introduce the constant TYPE in every interface and give it a world wide
number as is the case now. A test could then be something like this in
the Java

  if (someNode.getNodeType() == org.w3c.dom.core.Element.TYPE)

- A document is in fact a tree. This is expressed by the fact that a lot
interfaces are derived from core::Node. With the core module we can
manage the parse tree of a document. This leads me to think that I would
the document type node, if there is any, in the child list of a
core::Document node and that the core::Document::documentType attribute
is just
a convenience attribute. Is this interpretation correct? In that case
the same
goes for all attributes of type core::Node in xml::DocumentType for

- If the above interpretation is correct I think that this principle
should be
taken further. It should be possible to navigate through the complete
into its smallest detail by only using the core::Node interface.
Run-time type
checking provides the necessary information while navigating. This way
we would
have a real parse tree of the document. To achieve this more interfaces
should inherit from core::Node.

- This would lead to the following modifications:
  - Deriving core::Attribute from core::Node. It simplifies the
interface. Its attributes operation could become an attribute of type
core::Node. core::AttributeList would be obsolete. Note that in the xml
same kind of relationship exists between ElementDefinition and
  - Deriving xml::DocumentType from code::Node. This is necessary
because the
type of the attribute core::Document::documentType is core::Node.
  - Deriving xml::EntityDeclaration from core::Node. This is necassary
the type of the attributes xml::DocumentType::generalEntities and
xml::DocumentType::parameterEntities is core::Node and thus their
children, the
entity declarations, must be of type core::Node as well.
    The xml::EntityDeclaration interface should also have a name
  - Deriving xml::EntityReference from core::Node. It should have a name
attribute. The expand operation should replace the node by a text node
or a
document fragment according to what is available in the entity
declaration. The
replacement string and subtree should be mutually exclusive.

With kind regards,
Werner Donn
Leuvenselaan 172
B-3300 Tienen
tel: (+32) 16 810203
fax: (+32) 16 820826
E-mail: wdonne@ibm.net
Received on Thursday, 9 April 1998 11:18:15 UTC

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