Lists Home |
Date Index |
- From: <firstname.lastname@example.org>
- To: <email@example.com>
- Date: Sun, 20 Sep 1998 22:45:49 -0400 (EDT)
Don Park writes:
> >Sure, but in SAX (event stream) to DOM conversion, you need to
> >capture *all* the SAX events if you are to be able to satisfy the
> >guarantees that the DOM model makes. You can't just decided to
> >start DOMifying at some random element, because by then you have
> >forgotten what the parent element is. You either have to reify
> >the SAX events and store them as such, or else create the DOM
> >Nodes on the fly whether the user claims to want them or not.
> Right. Lazy evaluation is not possible when building DOM using SAX.
The problem is really with the XML parsing model as much as with SAX
-- XML is designed to be parsed only from the top down, though in the
past I have suggested ways that the parsing could be parallelised. It
is easy to imagine lazy evaluation on top of a database, but very hard
to imagine it from a physical XML document.
That said, I can think of two possible solutions to the
lazy-evaluation problem, including the one which Don has already
1. Cache the event stream in a compact format.
2. Reparse the document on demand (i.e. when the user climbs out of
the subtree and/or tries to do something with the document node) --
in this case, you need only store the treeloc of the element.
The first solution is still greedy, but would be reasonably fast and
less resource-hungry than a naive DOM implementation. The second
solution could be very slow when someone tried to climb out of a
subtree, but it would not make great demands on memory.
Essentially, you should choose #1 if you think that users are likely
to need to climb out of the subtree fairly often, and #2 if you think
that it will be rare.
All the best,
David Megginson firstname.lastname@example.org
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)