[
Lists Home |
Date Index |
Thread Index
]
Hi,
I just read through a pair of articles on XML (XML is too hard for
programmers, and Why XML doesn't suck), and thought you might be interested
in a different approach. I have recently needed an XML parser that is
capable of parsing seriously huge amounts of data (machines with half a gig
of memory would regularly fall over from the weight of the tree). I too
share a dislike of callbacks with the author of the piece, but I was using a
different language and so the solution is invariably different (I was using
the lazy-functional language, Haskell). In a lazy functional language a list
is like a stream or FIFO (but with no special syntax for the programmer) -
This means that if you represent the DOM as a list of elements with their
respective tree depths, the parser can stream the DOM out, (the
imlementation does not stop on a non-compliance, rater it anotates the error
as meta-data to the DOM and continues - allowing the application to choose
if the condition is fatal). You can write filters to extract the data very
simply, and combine filters using function-composition, or a Monad. The
whole assembly uses very little memory as the data is effectively streamed
through the composed filters, with the tree stucture is encoded in the depth
information. I am not sure if this model could be applied to
non-lazy-functional languages without loosing a lot of the benefits, it
would certainly work for simple filters, but without the ability to use
function composition on the filters to create more complex filters, it may
be not as useful. (I appreciate this description is rather terse, and am
willing to provide more datail should anyone be interested...)
Regards,
Keean Schupke, ACGI BEng MIEE,
Computer Support Group,
Department of Electrical & Electronic Engineering,
Imperial College London.
|
