Re: DOM Level 1 Becomes a W3C Recommendation

Mike Champion <mcc@arbortext.com> writes:

> There has been some sentiment expressed to define a 'server-side DOM' or a
> 'canonical DOM' or whatever that would be a conformance level that is more
> suited to high-performance applications written by expert programmers.  The
> idea is basically on hold, partly because there is a W3C effort to define a
> 'canonical' subset of XML, and it would make sense to tailor the 'canonical
> DOM' to that. (For example, *if* that subset of XML does not support
> entities, then probably the canonical subset of the DOM should not support
> entities). If this idea is important to anyone, lobby for it!

I'm in _VIOLENT DISAGREEMENT_ with this idea.  HTML is _never_ going to be a
subset (canonical or otherwise) of XML; they are _both_ subsets of SGML.

The ``cannonical'' DOM should be a _SUPERSET_, not a subset; it should be
capable of representing _any SGML document_ efficiently.  You do this by
_relaxing_ restrictions, not by imposing new ones.  One could even argue
(and I would like to so argue) that the ``cannonical'' DOM should not even
be restricted to SGML but should be capable of representing documents, and
collections of documents, in what SGML would call ``other notations''. 

Ideally one should be able to model the entire Internet as a collection of
DOM objects.  One should be able to write any SGML document-processing
application using the DOM.  Otherwise it's only going to be useful for a
decreasing subset of document processing applications, which will migrate
to, for example, DSSL. 

This is actually rather easy to do.  It requires, among other things,

  Defining some of the more egregious bits of Level 1 hand-holding (like
  ``live'' nodelists) as ``features''.  In fact, making <em>every</em>
  restriction of this sort a feature.  This would permit formal levels,
  including some future ``cannonical XML'', to be defined in terms of
  their required and prohibited features. 

  Removing restrictions on child types.

  Extending DocumentType so that it can actually represent an SGML DTD,
  possibly with extensions.

  Making it easy to define new node types (perhaps by requiring the result of
  Node::nodeType to be an index into a NodeList of node types).

  Bringing back iterators.

  Permitting implementations that do not require an entire document to be
  represented in memory at once.

  Permitting structure sharing. 

-- 
 Stephen R. Savitzky   Chief Software Scientist, Ricoh Silicon Valley, Inc., 
<steve@rsv.ricoh.com>                            California Research Center
 voice: 650.496.5710   fax: 650.854.8740    URL: http://rsv.ricoh.com/~steve/
  home: <steve@starport.com> URL: http://www.starport.com/people/steve/

Received on Thursday, 1 October 1998 15:48:17 UTC