Re: Cut/Paste from one document to another

Arnaud Le Hors <lehors@w3.org> writes:

> "Stephen R. Savitzky" wrote:
> > 
> > I don't recall seeing anything in DOM level 2 (not DOM 2.0) that changes
> > _anything_ in level 1.
> 
> I surely hope there isn't anything like that indeed, because we
> certainly don't want to break backwards compatibility.

At one point there was talk of relaxing some of the behavioral restrictions
(e.g. live NodeLists and live children on EntityReference nodes) in a way
that would preserve compatibility (in the sense that any Level 1
implementation would be a Level 2 implementation, but not necessarily vice
versa).  This would have made Level 2 easier to implement, more efficient,
and more generally useful.  Right now it's the opposite. 

> > It's all a bunch of additional interfaces that (in
> > my opinion) still aren't particularly useful outside the scripting
> > environment that the DOM is intended for.
> 
> Scripting? I'm not sure what you mean. Independently of your programming
> environment DOM Level 2 introduces some important new pieces such as
> support for namespaces, to only name one. This may not be useful to you
> but it is to many others.

The DOM is, first and foremost, the object model for ECMAscript.  It is
almost unuseable in applications where documents are being created, edited,
or transformed, because things like references to character entities,
omitted end tags (permissible in HTML), whether or not attribute values are
quoted, and the DTD are lost, making it impossible to reconstruct an
original document.  (To give just one example, I might want to use a
character entity to represent "@" in an e-mail address in order to foil
spammers.  There doesn't appear to be any way to represent such a thing in
the DOM, because character entities have to be converted to text on input.)

Similarly, there's no general technique for adding arbitrary application-
specific annotation to DOM nodes, such as would be needed for, e.g., a
rendering engine.  This has to be done by means of application-specific
extensions, which destroy portability.

I'm not saying that the additional features of Level 2 aren't useful, just
that they don't significantly extend the range of applications in which the
DOM can be used.  It's still mainly aimed at scripting in the browser. 

> > The DOM is most emphatically NOT a general-purpose, easily-implemented,
> > least-common-denominator interface for SGML.  It was never intended to be
> > and, as far as I can tell, never will be.
> 
> This is definitely correct. Our charter only lists HTML and XML as our
> target languages.

Nevertheless, it would take only a few very minor extensions (such as the
ability to represent the DTD, and a flag for omitted end tags) to make the
DOM capable of representing any SGML document.  Similarly, it would take
only a few changes (to the behavioral spec, not even the interfaces) to make
the DOM easier to implement, more efficient, and useful in a wider range of
applications. 

Restricting the DOM to HTML and XML in a browser-based scripting environment
is (in my opinion) shortsighted, and will eventually lead to another,
incompatible, standard for use in document-processing applications.

-- 
Stephen R. Savitzky  <steve@rsv.ricoh.com>  <http://rsv.ricoh.com/~steve/>
Quote of the month:  Death is nature's way of telling you to slow down.
Chief Software Scientist, Ricoh Silicon Valley, Inc. Calif. Research Center
 voice: 650.496.5710  front desk: 650.496.5700  fax: 650.854.8740 
  home: <steve@theStarport.org> URL: http://theStarport.org/people/steve/

Received on Wednesday, 1 September 1999 11:12:35 UTC