OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   DOM Confusion

[ Lists Home | Date Index | Thread Index ]
  • From: Ray <ray@guiworks.com>
  • To: xml-dev@ic.ac.uk
  • Date: Thu, 30 Apr 1998 07:41:31 -0600 (MDT)

In http://www.w3.org/TR/WD-DOM/level-one-xml.html, the XMLNode
interface is defined and explained as "the XML implementation
of the Node interface adds some methods that are needed
to manipulate specific features of XML documents"

the interface is defined as

interface XMLNode {
    Node                getParentXMLNode(in boolean expandEntities);
    NodeIterator        getChildXMLNodes(in boolean expandEntities);
    boolean             hasChildXMLNodes(in boolean expandEntities);
    Node                getFirstXMLChild(in boolean expandEntities);
    Node                getPreviousXMLSibling(in boolean expandEntities);
    Node                getNextXMLSibling(in boolean expandEntities);
    EntityReference     getEntityReference();
    EntityDeclaration   getEntityDeclaration();

Which basically defines functions identical to the ones in the Node
interface in the DOM core, except that now you can choose whether
entities are expanded or not. (which is cool)

However, I don't completely understand how this fits with the DOM

Am I to assume that, if I am operating on an XML document, all
functions that return a Node interface, actually hand me back
something that is an XMLNode instead? Indeed, if I get back
an Element, it is not Element : Node, but an Element : XMLNode?

My confusion comes from the fact that XMLNode doesn't inherit from
Node in the DOM spec. Thus, XMLNode doesn't have functions on
it like Node.getFirstChild(), or does it?

Since XMLNode itself defines functions like

    Node                getParentXMLNode(in boolean expandEntities);

Which return Node, not XMLNode, then either XMLNode does indeed inherit
from Node (and the Node object returned is actually an XMLNode), OR,
a compliant DOM interface must return objects that look like this

class MyNode implements org.w3c.dom.Node, org.w3c.dom.XMLNode

That way, they can be cast from Node <-> XMLNode, which seems ok,
but nowhere in the DOM spec does it say that all Core objects
will implement both interfaces if you are operating on XML.

Given that I didn't pay my $5000, I can't really register my compliant
on the WG list, but I have two questions:

1) If XML node doesn't inherit from Node, and is inherently
specialized, why doesn't  

Node                getParentXMLNode(in boolean expandEntities);

for instance, return XMLNode. An why not define XMLElement, XMLPI, 
etc... that all inherit from XMLNode?

2) DOM seems to go from the "general to the specific" which is good,
for instance, the core defines PI nodes, but HTML (more specific)
has no PI elements.

So why not dispense with XMLNode altogether and make the Node
interface implement these functions? Simply define that expandEntities
is "always true" for HTML documents, or some such.

3) extra nit: the function names are overly verbose and option #2
would solve it.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS