W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2001

Proposal: Lazy evaluation

From: Robin Green <r.d.green@lancaster.ac.uk>
Date: Mon, 1 Jan 2001 21:34:17 -0500 (EST)
To: www-dom@w3.org
Message-ID: <Pine.GSO.4.21.0101020215060.22021-100000@unixb.lancs.ac.uk>
I'm investigating possibilities for converting objects from an object
database into DOM fragments (for use in the XML publishing framework,
Cocoon). I would like to do a sort of "deep convert" so that an object,
all its fields, all _its_ fields, etc. would be converted recursively.
I did think of actually _implementing_ a DOM myself so I wouldn't have to
convert the objects, but this will generate WRONG_DOCUMENT errors on at
least some DOM implementations.

First problem - the DOM generated may be excessively large, generating
more data than is actually needed by the presentation layer, which is
inefficient. Secondly, there may be cycles in the object graph, which
means that a naive conversion algorithm would go into an infinite loop!

Both of these issues could be addressed by specifying a maximum recursion
depth. However, it is conceivable that the optimum recursion depth may not
be easy to determine at conversion time. Thus, I would like to suggest a
facility in the DOM for lazy evaluation. It would be a proxy node which
you would pass a callback function, and the callback function would only
actually be called, to create the real node, if and when the node was
referenced (i.e. when getChildNode or whatever was called). In other
words, the very act of requesting the node would create it (this
modification might have to be specifically excluded in the specification
from the definition of a non-modifiable document).

Issues:

* Language-independent callbacks??

* Exceptions could happen at unexpected times (but, in my experience, this
problem crops up almost everywhere!)

* This would allow infinitely deep DOMs, and there would be no obvious way
for DOM clients to detect the problem of an infinitely deep DOM.

However, it would be useful from an efficiency point of view.

Comments?
Received on Tuesday, 2 January 2001 09:39:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:48 GMT