On 03/22/2010 05:42 PM, Andrew Sutton wrote:
I think that Apache's xerces would make a good second such target. MSXML would probably be a better option. Expat... Maybe.
OK. The only problem I can see with MSXML is that it's a platform-specific library, which constrains the ability to use (and test).
I think that the project depends on the interface that you want to expose. I'd like to see a uniform method for opening XML files (preparing them to be parsed?), opening buffers for parsing, saving files?, etc.
My DOM API has one function to generate a DOM-tree from an XML file, and one to generate an XML file from a DOM-tree. I'm not sure anything else is needed, as far as parsing is concerned. Of course, SAX and XMLReader are a different story...
I'm guessing that a SAX-based interface wouldn't be too hard. I can't imagine that SAX providers don't expose wildly different APIs.
Right, though there are non-SAX (post-SAX ?) APIs that are considered better than SAX, notably XMLReader.
How does this sound ? Is there any interest in this ? Such an endeavor may
also help rebut some of the arguments against the current approach, and thus help move us further towards an acceptable and official solution.
Well, I'm interested :) I think designing by the committee is the wrong way to go these libraries (XML, BigInt, etc.). I say wrap up the stuff that's out there and figure out where the problems come as we go. Nothing's ever perfect the first time you do it, and this isn't one of those times where it needs to be.
True. OK, let me put it this way: The goal here should be to define an API. I have an existing implementation that wraps libxml2. I welcome any proposal for alternate implementations / backends. Be warned, though, that I consider XML compliance a prerequisite, not an optional feature. :-) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...