Sean Parent wrote:
There is a Boost xml, but I haven't seen much Boost activity here. Property tree does some too, but full XML support is hard enough that it will be hard to do in Boost.
http://www.boost-consulting.com/vault/index.php? direction=0&order=&directory=Progamming%20Interfaces
We're getting close to a complete XML parser - this is not a DOM, the idea is that a DOM would be a separate library that could be used with the parser - but the parser can be used just fine without a DOM.
Is my impression correct that the Adobe parser is a push parser? In my opinion, a general parser should be implemented as a pull parser, and the push parser should be implemented on top of it. This is for two simple reasons: 1) Some people will want a pull parser, so the library ought to provide one. 2) Implementing a push parser on top of a pull parser is as easy as getting tokens in a loop and dispatching them. The other way round is not easy at all. You can either parse the entire document on the first pull call, thus losing streamability and having to buffer everything, or you use some sort of context switching, which is hard to implement and has a high overhead. (Threads are actually overkill for this. Win32 Fibers would do, and it should even be possible using setjmp/longjmp - but I wouldn't want to do it.) I said I'd take on Boost.Xml, but I'm still in the design and experimentation phase (the scanner is frustrating me). If you don't mind, I'll see if I can reuse as much code from Adobe.Xml as possible. Sebastian Redl