Cart
[Home] [By Thread] [By Date] [Recent Entries]
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: > > <snip/> 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 types. 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? >> >> > >Document order. > > : ) -- Burak Emir http://lamp.epfl.ch/~buraq
|
