Michel Fortin wrote:
On 2009-08-01 00:04:01 -0400, Benji Smith <[email protected]> said:
But XML documents aren't really lists. They're trees.
Do ranges provide an abstraction for working with trees (other than
the obvious flattening algorithms, like breadth-first or depth-first
traversal)?
Well, it depends at what level you look. An XML document you read is
first a list of bytes, then a list of Unicode characters, then you
convert those characters to a list of tokens -- the Tango pull-parser
sees each tag and each attribute as a token, SAX define each tag
(including attributes) as a token and calls it an event -- and from that
list of token you can construct a tree.
The tree isn't a list though, and a range is a unidimentional list of
something. You need another interface to work with the tree.
But then, from the tree, create a list in one way or another
(flattening, or performing an XPath query for instance) and then you can
have a range representing the list of subtrees for the query if you
want. That's pretty good since with a range you can lazily iterate over
the results.
Oh sure. I agree that a range-based way of iterating over tokens is
cool. And a range-based API for walking through the results of an XPath
query would be great. But the real meat and potatoes of an XML API would
need to be something more DOM-like, with a tree structure.
The only reason I chimed in, in the first place, was Andrei's post
saying that a replacement XML parser "ideally outputs ranges".
I don't think that's right. Ideally, an XML parser outputs a tree structure.
Though a range-based mechanism for traversing that tree would be nice too.
--benji
