> > The problem comes if the parser tries to build a tree rather than
> > simply reporting an event stream.
>
> How many real world applications will be happy with just the event
> stream ? XSL-visualization always needs two trees, the parser tree
> and the resulting Formatting Object Tree (FOT). Double impact ! XML-
> querys/DOM need to build a transformed versions. Triple impact !
Yes, but often the trees can be built and discarded at a fairly low
level. For example, if I have a serialised database table like
<table>
<entry>
<name>David Megginson</name>
<email>david@megginson.com</email>
</entry>
<entry>
<name>Ingo Macherius</name>
<email>macherius@darmstadt.gmd.de</email>
</entry>
<!-- etc., 2,500,000 times -->
</table>
I do not need to build a tree for the whole document; instead, I can
cache the information for each entry (or each n entries, for
efficiency), dump it into my SQL database (or whatever), then move on
to the next set.
The second situation is where you are using XML to serialise a data
model that is already well-defined (as for vector graphics). In this
case, it makes more sense to build the specialised object tree
directly from the event stream rather than building a DOM tree only to
tear it down. Specialised object trees can be considerably smaller
than a corresponding DOM tree, depending on the format.
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/