Re: DOM L2 comments, various

David Brownell <david-b@pacbell.net> writes:

> "Stephen R. Savitzky" wrote:
> > 
> > David Brownell <david-b@pacbell.net> writes:
> > 
> > > "Stephen R. Savitzky" wrote:
> > > >
> > > > It's a problem -- there _has_ to be some extension mechanism defined
> > > > in the spec.
> > >
> > > The spec allows anyone to define, for example, new interfaces (outside
> > > of the org.w3c.* space) and implement them, as well as persuade others
> > > to implement them.
> > 
> > But you might need (or _want_) to define new interfaces that descend from
> > Node; in that case you would need node types for them.
> 
> Could you give an example?  Is there some syntax that's significant
> and not part of the DOM already?  (Excluding DTD syntax.)

Why should I exclude the DTD?  It seems to be a perfectly valid example of
something that an application might want to manipulate.  

For that matter, why are things like style-sheet components NOT descended
from Node?  Is there some reason why they shouldn't be?

How about scripts?  An application, such as an interpretor, might want to
parse the contents of a <script> Node and represent the resulting parse
tree as something that can be manipulated using the DOM interfaces, but
clearly Javascript statements don't have the syntax of Elements. 

> The HTML DOM defines interfaces that descend from Node, but they're
> all just convenience functions over the core APIs -- they're all
> still existing node types.

That's true, but all of them are subclasses of Element.  It's not clear to
me that the content of a <script> node should be, for example. 

> > > > I guess I don't see why element and attribute declarations would need
> > > to look like DOM "Node" objects except for a JavaScript environment.
> > 
> > Because DocumentType is a Node, and the declarations ought to be children of
> > the DocumentType.  Because some applications may want to be able to handle
> > arbitrary SGML documents instead of just HTML and XML.  Because Javascript
> > isn't the only language in the universe without type declarations.  Because
> > someday the DOM _will_ be extended to handle the DTD, and in the interim
> > people need a consistent way of experimenting with the expected structure.
> > 
> > It's not that you can't kludge around the problem in some cases, it's just
> > that it's much cleaner if you don't have to.
> 
> But I'd say "cleaner" is the job for the DOM itself to fix.  And yes, it's
> probably overdue that it be fixed.

I don't think that the DOM is able to fix these problems.  Certainly the
DOM's becoming "cleaner" is totally out of the question at this point.  It's
so tied to the browser/Javascript environment that it's simply impossible to
adapt it to other environments, such as low-memory, large-document,
document-creation, or server-side applications.  In order to "fix" it one
would have to abandon, or at least limit, compatibility with the existing
Level 1 (and now Level 2) specifications.

The biggest problem with the DOM is that it's trying to be _THE_ DOM, when
in fact it's merely _A_ DOM.  One of the oft-touted features of XML is that
it's fairly straightforward to model _any_ data structure using it.  But the
DOM puts so many constraints on the implementation that this becomes
impossible -- you CANNOT model any data structure with the DOM except a
multiply-linked tree, with no structure sharing, all of which fits in
memory. 

> > 	It's always better to have an explicit extension
> > mechanism in the spec, so that each application doesn't go off in its own
> > completely incompatible direction.
> 
> True enough.  And it can reduce abuses like intentional violations of
> such specifications ... ;-)

Exactly.  I'd like to have a specification that I don't have to violate in
order to get my application to work. 

-- 
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 Monday, 4 October 1999 16:22:29 UTC