W3C home > Mailing lists > Public > www-dom@w3.org > October to December 1998

Re: Relation between core DOM and HTML DOM

From: Arnaud Le Hors <lehors@w3.org>
Date: Wed, 14 Oct 1998 10:53:35 +0200
Message-ID: <3624668F.AC3C7B69@w3.org>
To: "'DOM list'" <www-dom@w3.org>
Miles Sabin wrote:
> 
> On the face
> of it the HTML classes are, roughly speaking, convenience classes,
> supplying convenience methods over and above those provided by the core.

This is mostly correct although the DOM only defines interfaces, not
classes. There is an important distinction here.

> If that were the case then we ought to expect that the following two
> DOMs ought to be, to all intents and purposes, equivalent ...
>
>   import org.w3c.dom.*;
>   import com.cromwellmedia.dom.*;
> 
>   Document doc = new BasicDocument();
>   Node html = doc.appendChild(doc.createElement("HTML"));
>   Node head = html.appendChild(doc.createElement("HEAD"));
>   Node title = head.appendChild(doc.createElement("TITLE"));
>   title.appendChild(doc.createTextNode("The title"));
>   Node body = doc.appendChild(doc.createElement("BODY"));
>   Element image = doc.createElement("IMG");
>   body.appendChild(image);
>   image.setAttribute("src", "foo.gif");

The DOM Level 1 doesn't define how a document is created but I would
expect this to rather use something like:

   Document doc = new BasicDocument("HTML");

So that the proper type of document is created. 


> and,
> 
>   import org.w3c.dom.*;
>   import org.w3c.dom.html.*;
>   import com.cromwellmedia.dom.html.*;
> 
>   HTMLDocument doc = new BasicHTMLDocument();
>   HTMLFactory fact = doc.getHTMLFactory();
>   Node html = doc.appendChild(fact.createHtmlElement());
>   Node head = html.appendChild(fact.createHeadElement());
>   doc.setTitle("The title");
>   Node body = html.appendChild(fact.createBodyElement());
>   HTMLImageElement image = fact.createImageElement();
>   body.appendChild(image);
>   image.setSrc("src", "foo.gif");

Well, your example seems to be based on an old draft. There is no longer
any factory. Once changed according to the DOM Level 1 Recommendation
this would look more like:

  import org.w3c.dom.*;
  import org.w3c.dom.html.*;
  import com.cromwellmedia.dom.html.*;

  HTMLDocument doc = new BasicHTMLDocument();
  Node html = doc.appendChild(doc.createElement("HTML"));
  Node head = html.appendChild(doc.createElement("HEAD"));
  doc.setTitle("The title");
  Node body = html.appendChild(doc.createElement("BODY"));
  HTMLImageElement image = (HTMLImageElement) doc.createElement("IMG");
  body.appendChild(image);
  image.setSrc("foo.gif");

With this I would expect both to represent:

>   <HTML>
>     <HEAD>
>       <TITLE>
>         The title
>       </TITLE>
>     </HEAD>
>     <BODY>
>       <IMG src="foo.gif">
>     </BODY>
>    </HTML>


> However, typical core DOM implementations are not going to be aware of
> the special characteristics of HTML,

There is no such thing as "core DOM implementations". You either have an
XML DOM implementation (this is Core + XML extensions) or an HTML DOM
implementation (this is Core + HTML), or possibly an implementation that
does both.

> so various operations defined over
> these two DOMs will behave differently, viz.
>
>   image.getAttributeNode("SRC")
> 
> will return non-null for the HTML DOM, because HTML attribute names are
> case-*insensitive*, whereas it will return null for the core DOM,
> because core attribute names are case-*sensitive*.

This is wrong. Attribute names just like element names are
case-sensitive for XML documents and case-insensitive for HTML
documents. No matter what interface you're using. I wish the spec was
clearer on this actually, I just checked and although nothing says
otherwise it's not clearly stated either, but I can garantee you that
what's intended.

> Here's another case which illustrates some of the problems which might
> crop up for implementors. Suppose we have a DOM which combines instances
> of classes from both the core and the HTML DOM, owned by a core DOM
> document,

Again, there is no such thing as a "core DOM document". Your document is
either XML or HTML. That's what matters.

> But this will, of course, fail for the example given, because
> the ancestor TABLE element is an instance of a core DOM class, obtained
> from a core DOM document factory method.

No. If you're dealing with an HTML document, all the elements in the
document are HTML elements. No matter how you created them. See that's
where the distinction between classes and interfaces becomes really
important. There is no such thing as a "core DOM class". You should only
encounter HTML DOM classes or XML DOM classes. These classes will also
happen to implement a core DOM interface and therefore can be seen as
"core DOM classes", however they truly are either HTML or XML DOM
classes.

> At
> the very least it would need an additional requirement that HTMLXXX
> elements can only be owned by documents which implement the HTMLDocument
> interface.

Hmm, maybe the spec needs clarification on that front. But this clearly
is the intent.

> If that were the case then implementations of HTMLDocument
> could override the Document factory methods to ensure that all nodes in
> the tree were instances of classes which implement the appropriate
> HTMLXXX interfaces.

This is what I expect for sure.
-- 
Arnaud  Le Hors  -  W3C, DOM Activity Lead  -  www.w3.org/People/Arnaud
Received on Wednesday, 14 October 1998 04:53:40 GMT

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