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

Re: The DOM is not a model, it is a library!

From: Stephen R. Savitzky <steve@rsv.ricoh.com>
Date: 07 Oct 1999 09:36:02 -0700
To: "Michael Champion" <michael_champion@ameritech.net>
Cc: "DOM Mailing List" <www-dom@w3.org>
Message-ID: <qcwvszp1ql.fsf@congo.crc.ricoh.com>
"Michael Champion" <michael_champion@ameritech.net> writes:

> ----- Original Message -----
> From: Stephen R. Savitzky <steve@rsv.ricoh.com>
> > My Java implementation, also with (a different set of) extensions is about
> > twice that and is also _almost_ complete.  But making it fully compliant
> > would mean rewriting large parts of my application, so it isn't going to
> > happen.
> One major purpose of the "Last Call" period is to let implementors give the
> working group feedback on the difficulty, efficiency, etc. of various items
> in the spec.  It would be very helpful to get specific feedback from
> developers as to WHICH 10% of the spec gives the most trouble, etc.

1. Live nodelists are trivial to implement badly, but useless in practice. 

   Specific fix: add operations to DocumentTraversal to construct a
   NodeIterator from a NodeList and from a NamedNodeMap.  This allows the
   problematic NodeList objects to exist only transiently before being
   replaced by something efficient. 

2. The new ownerElement attribute of Attr is a major nuisance because it
   means it's impossible to share default values from the DTD.

   Specific fix:  permit (or require) ownerElement to return null from an
   Attr for which specified is false. 

3. Requiring the children of an EntityReference to exist and be identical to
   the children of the corresponding Entity is horrendous. 

   Specific fix: make this a feature.  Better, allow it to be enabled or
   disabled by the application at the Document level.  It's much better for
   many applications if they look up the Entity.  Turning on
   expandEntityReferences in a TreeWalker would do this automatically
   without requiring the application to do anything.   

   It would be necessary to make it clear that, when a TreeWalker descends
   into the ``children'' of an EntityReference, parentNode of those children
   might refer to the Entity rather than to the EntityReference. 

4. The requirement that the entire document be accessible is onerous for
   applications with limited memory and no external storage.  One could not,
   for example, put a DOM on a Palm Pilot. 

   Workaround: enable a TreeWalker (perhaps under the control of some new
   attribute) to return a shallow clone of the current node rather than the
   node itself; add another attribute to make the TreeWalker unidirectional.
   This isn't as good as a complete set of tree traversers and constructors
   that can completely insulate an application from the Nodes, but it's
   better than nothing. 

5. No way for an application to attach its own information to the tree.

   Specific fix: add a new attribute to Node:

	attribute NamedNodeMap applicationData;

   It must be explicitly permissible for the items in the map to come from
   any mixture of owner documents, and indeed from any mixture of DOM
   implementations (this might have to be a feature).  This would allow an
   application to construct a Document containing sharable metadata with
   which it can then decorate some other Document with the application, not
   the DOM, controlling whether sharing is to occur.

   Allowing application data to come from different DOM implementations
   would allow an application to decorate a document from some third-party
   library with its own extended nodes if it had them.

These, taken together, would allow my application (for example) to actually
make use of someone else's DOM implementation rather than my own hacked-up
extended subset, although performance would still suffer dramatically.

The application in question is open source; see the second line of my
signature below.

Stephen R. Savitzky  <steve@rsv.ricoh.com>  <http://rsv.ricoh.com/~steve/>
Platform for Information Applications:      <http://RiSource.org/PIA/>
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 Thursday, 7 October 1999 12:36:38 UTC

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