Michel Fortin wrote:
> Benji Smith wrote:
Usually, I use something like XPath to extract information from an XML
doc. Something liek this:
auto doc = parser.parse(xml);
auto nodes = doc.select("/root//whatever[...@id]");
I can see how you might do depth-first or breadth-first traversal of
the DOM tree, or inorder traversal of the SAX events, with a range.
But that's now how most people use XML. Are there are other range
tricks up your sleeve that would support the a DOM or XPath kind of
model?
A range is mostly a list of things. In the example above, doc.select
could return a range to lazily evaluate the query instead of computing
the whole query and returning all the elements. This way, if you only
care about the first result you just take the first and don't have to
compute them all.
Ranges can be used everywehere there are lists, and are especially
useful for lazy lists that compute things as you go. I made an XML
tokenizer (similar to Tango's pull parser) with a range API. Basically,
you iterate over various kinds of token made available through an
Algebraic, and as you advance it parses the document to get you the next
token. (It'd be more useful if you could switch on various kinds of
tokens with an Algebraic -- right now you need to use "if
(token.peek!OpenElementToken)" -- but that's a problem with Algebraic
that should get fixed I believe, or else I'll have to use something else.)
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)?
--benji
