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

"Ray D. Whitmer" <rayw@imall.com> writes:

> On 7 Oct 1999, Stephen R. Savitzky wrote:
> 
> >1. Live nodelists are trivial to implement badly, but useless in practice. 
> 
> Live nodelists are trivial to implement so that they are efficient as long
> as the tree is not mutated during use. 

But how can you tell?  I suppose you could put a pseudo-timestamp in the
document root...

> >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. 
> 
> This is not new with the addition of the ownerElement.  Please, explain to
> me how you can possibly share the Attr node object directly under the level
> 1 API.  When the user does a setNodeValue on the attribute, are you going to
> change the value of that attribute for all elements which happened to have
> the old value in the tree?  If you are not, then you have to create at least
> a temporary object to hold the attribute's position in the tree.

Actually, in some cases you might _want_ to be able to change the default
value.  Changing the value associated with a single element would be done
only via setAttribute or setAttributeNode, which would always create a local
Attr attached to the Element. 

In Level 2 there's no way to change the default value which, as I said,
could be useful in some cases.

> FWIW, there is no requirement in DOM that the Java == function identify that
> two nodes are the same node.  You can create temporaries on the fly that
> get garbage collected.  This point may not be clear in the spec, but it
> needs to be, and was always hard-fought to keep it that way.

It needs to be made clear in the spec, then; there's normally an expectation
that == works. 

> >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. 
> 
> Returning the shallow clone is easy to do with the current API.  Lots of
> different lazy loading schemes are also possible.

I don't think so -- unless otherwise noted it would be assumed that, for
example, previousSibling on the returned node would work.  Lazy loading
doesn't do you any good if you want to stream through a huge document and
throw away the nodes you're no longer interested in.  Admittedly, my
requirements are slightly bizarre. 
	 
> I don't see the need to make the thing unidirectional -- I think that most
> constraints can be addressed in other ways.  I fully plan on having a lazy-
> loading DOM that works well for palm pilots.  This is easy with the current
> API.  And it doesn't rely on TreeWalker.  I'd be happy to discuss a variety 
> of techniques...

Again, this only works if you keep the whole tree around _somewhere_.  In
my case I want to be able to guarantee that I never have to keep it at all;
documents just stream through. 

> >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;
> >
[...]
> 
> I strongly agree that it is nice to be able to attach data to a node of the
> DOM, and this could easily turn out to be one of the first things we add for 
> level 3, as soon as we are able to address the legitimate concerns.
> 
> I am opposed to a single attribute, because it means that when you have
> multiple DOM applications working on the same tree and using this for
> different extension purposes, they collide.  Why limit extensions
> this way?  I also think there are times when this data needs to be
> cloned/copied with the node.  Otherwise, cut and paste can lose important
> data, so a small accomodation is needed during node cloning, IMO.

Correct me if I'm wrong, but I thought that the implicit use case has always
been that an application is handed a document, grovels over it for a while,
and exits (or gets handed another document); I don't think the DOM was ever
intended as a model for persistent storage or even for multi-threaded
applications.  Which is not to say that persistent tree storage with
persistent metadata wouldn't be good to have.

On the other hand, being able to control which metadata gets cloned with the
node, which gets shared, and which gets thrown away would be a good idea.

> One other concern is shared data.  My DOM shares everything whenever it
> is the same.  For example, all similar whitespace is a single object
> in my DOM.  All identical attributes are a shared object, and so on.
> Attaching unique data makes this more difficult, but I think I can solve 
> it, so I am for the proposal.

Nice.  So leaf nodes are shared, and only the Element nodes are actually
linked into the tree?  Or do you share Element nodes as well?  In either
case I can see why == doesn't work in your system. 

-- 
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 Monday, 11 October 1999 11:06:08 UTC