core::Node and inheritance

Hi,

A few remarks about core::Node and inheritance:

- There is another problem with the constants defined in core::Node to
identify
the subinterfaces of Node. For interfaces outside of core there aren't
such
constants. However, classes implementing these interfaces must provide
something for Node.getNodeType. This means there must be a public
constant
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
unique
number as is the case now. A test could then be something like this in
the Java
case:

  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
of
interfaces are derived from core::Node. With the core module we can
actually
manage the parse tree of a document. This leads me to think that I would
find
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
example.

- If the above interpretation is correct I think that this principle
should be
taken further. It should be possible to navigate through the complete
document
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
core::Element
interface. Its attributes operation could become an attribute of type
core::Node. core::AttributeList would be obsolete. Note that in the xml
the
same kind of relationship exists between ElementDefinition and
AttributeDefinition.
  - 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
because
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
attribute.
  - 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é
Re BVBA
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