Lists Home |
Date Index |
John Cowan wrote:
>Burak Emir scripsit:
>>But, to process XML in a program, you can never do without the tree view.
>That's simply not true. The applications I support do significant
>XML processing with fgrep, because all they want to know is:
Right. Here "process in a program" was meant more like this: you have
three schemata A B C, from three independent places, and you have a
function to get from A to B and one from B to C (a function that does
more or less the same as an XSLT stylesheet or an XQuery expression).
Now I want to get from A to C directly, enchaining the functions. Then I
want to search C similarly to what you do with fgrep. Now I would expect
an XML aware programming language to find out what is going on and only
transform those bits that I need. This has actually been researched in
functional programming, but for quite restricted tree manipulations and
A could be some schema for storage in relations, B some intermediary
format, and C presentation layer. What should work in the small should
work in the large.
>Other programs process XML using SAX in a purely streaming fashion,
>and never build any explicit tree.
Yes, but if you want to do the above, one might have a hard time using
only callback methods. It will work for some things, and is fast, but in
general it is not convenient and can be clumsy. One can bring it to
work, but for the programmer it does not feel the same. Do people
actually enchain SAX handlers?
>>>SAX exposes probably the most popular non-tree model, but it's hardly
>>>the only one. Indeed there are non-event, non-tree models as well. Some
>>Aha, event-based and in which order are the events called?