thanks Joseph. That makes sense.
Alistair
On 14 Dec 2004, at 14:04, Joseph Kesselman wrote:
On Tuesday, 12/14/2004 at 01:09 GMT, "Alistair Young"
It seems to get
populated as you do things on it, such as getNodeName/getNodeValue
etc.
For instance, after parsing, DeferredDocumentImpl.firstChild is
sometimes
null, or points to a structure full of nulls. After calling
getNodeName/getNodeValue on the root node, firstChild is populated.
What's the difference between DeferredDocumentImpl and DocumentImpl?
That's precisely the difference.
DocumentImpl is part of a simple standalone implementation of the DOM
APIs.
DeferredDocumentImpl is part of the Xerces "Deferred DOM", used
specifically for DOMs created by the parser. For this implementation,
the
parser stores the document's contents in a more compact back-end form
and
expands them into DOM objects as you walk the DOM tree; this can
reduce the
amount of object churn if you don't need to look at the whole tree,
and may
(I'm not sure about this) also reduce latency before the first node is
available (though if it does, that may be at the expense of reduced
throughput before the last node is avaialable; that's the usual
pipelining
tradeoff.) I haven't looked at the exact details in a long time, so the
best I can suggest is that you read the code if you need more
specifics.
For a similar concept at a different trade-off point, see the DTM data
model that Xalan uses as its internal representation. (Actually, I just
thought of another way we might be able to optimize that, but I need to
work with it a while before I'll be convinced it's really a net win.)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
