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

My two cents on these five RFEs ...

- Dave

"Stephen R. Savitzky" wrote:
>
> 1. Live nodelists are trivial to implement badly, but useless in practice.

	The real fix is IMO recognizing liveness as the fundamental
	problem, and offering APIs without liveness.  Liveness is
	what costs.  It's easy to have an array be efficient, and to
	populate such an array with a data snapshot.  I've yet to need
	the liveness.


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

	That's not a new issue; it happened back in DOM L1.  All
	the new attribute does is expose state that was already
	required.


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

	I don't see what you're saying.  Neither one is _required_ to have
	any children, and "identical" is also undefined.  (Clearly it can't
	affect what getParentNode() returns, which must be different, so the
	nodes are not identical in the "same node" sense.)


> 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.

	Here's where I tell people not to use DOM.  It seems to me that
	data structures optimized for resource constained environments
	such as servers and PDAs need the flexibility to be incompatible
	with the megabrowser APIs of which "DOM Level 0" is a subset,
	and with which Level 1 and Level 2 "must be" compatible.


> 5. No way for an application to attach its own information to the tree.
> 
>         attribute NamedNodeMap applicationData;

	It's actually sufficient to have a single "Object" there, which
	can hold dictionaries or whatever is desired.  A NamedNodeMap is
	IMHO the wrong model since its contents are Nodes not arbitrary
	data ... and in any case, a policy would be needed to define how
	the names get managed.


	HOWEVER ... it's also possible for applications to maintain
	their own tables which map nodes to values of their choice,
	so I'm unconvinced this needs to be part of DOM.

Received on Thursday, 7 October 1999 15:26:20 UTC