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

About the DOM Level 2 HTML specification

From: Marco <marco@tinet.com>
Date: Wed, 28 Nov 2001 09:15:07 -0500 (EST)
Message-Id: <>
To: www-dom@w3.org
I'm relatively new to DOM, so perhaps I'm saying the obvious or I'm missing 
the point...

After reading the latest DOM Level 2 HTML specification, it seems to me that
the focus of DOM is to manipulate existing documents but not to create new 
ones from scratch.

My goal is to create programmatically (x)html documents without worring about
well-formness using classes that abstract the various elements instead of
writing out raw tags, so I turned to DOM and its implementations (for example,
the one included in Apache's Xerces).

Here are some limitations I found:
- HTMLDOMImplementation::createHTMLDocument creates only a bare html document:
   no way to create a xhtml document or to specify a DTD. OK, I can turn to the
   superclass (DOMImplementation), but I loose the HTMLDocument as resulting
   document (it's "only" a Document).
- in HTMLDocument there are convenient methods to access some of the
   document's elements, but surprisingly lacks a method to easily access the
   HEAD element (that is created by HTMLDOMImplementation::createHTMLDocument)
   the way you can access the BODY element.
- somewhere (probably in HTMLDocument) there should be methods to create
   instances of specific elements (for example, a createHTMLParagraphElement
   method). While a workaround exists via the method Document::createElement,
   the specification does not mandate (and I don't see how can it do it) that
   the new element must be of the right type (at least Xerces is smart enough
   to return a proper specific instance instead of a generic Element). Also,
   this has the drawback that you must specifiy the HTML tag, thus losing
- methods that return instances of specific elements (as
   HTMLDocument::getBody) should have a specific return type: in the example
   HTMLDocument::getBody should return a HTMLBodyElement, not just a

Clearly, you can work around these and other limitations, but you loose
flexibility and abstraction. Actually I'm using my own set of classes but this
is obviously not the best solution, since it's (almost) always better to reuse
classes already written (when available).

Received on Wednesday, 5 December 2001 18:51:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:09 UTC