An abstracted XML parser API would be useful to embedded and gaming platforms. Libxml is a fine library, but memory-constrained applications will usually have their own lean xml implementation and would like to avoid redundancy.
Regarding stream-based XML as opposed to SAX-based XML, we too find it to be a friendlier way. Our xml library is layered, with a stream implementation at the bottom, and optional SAX and DOM APIs on top of it. The SAX layer ends up being very thin, and I tend to think that if you have a stream API then it can usually or always be thinly wrapped to be a SAX API. Paul On Sep 10, 2008, at 4:08 AM, Arvid Nilsson wrote: >/ Hello, sorry to bring this old topic up again. Nothing has happened />/ in the last year or so, and this issue is bothering me again... />/ />/ I am thinking that libxml2 should be somehow considered "default" />/ since it is used by most existing ports, and also is quite portable, />/ making it likely that new ports will use it. Maybe this idea will />/ make it possible to make a patch that permits using something else />/ than libxml2 without having to patch build systems other than qmake. />/ />/ Would it be possible to use a variety on the ResourceHandle porting />/ approach and have a WebCore/dom/XMLTokenizerBase.{h, cpp}. The />/ libxml2 implementation lives in WebCore/dom/XMLTokenizer.{h, cpp}. />/ If you don't specify in your build system that you should use />/ WebCore/dom/port/XMLTokenizer.h and WebCore/dom/port/ />/ XMLTokenizerPort.cpp, you will get libxml2. />/ />/ An added bonus is that you don't have to come up with a better name />/ than "XMLTokenizerLibXml2.cpp" since it's still called />/ "XMLTokenizer.cpp". / I think we should wrap the XML parser API at the platform/ layer. The main risk in doing so would be performance. - Maciej >/ />/ />/ /Arvid />/ />/ On Sun, Jul 29, 2007 at 7:53 PM, Lars Knoll <lars at trolltech.com <http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev>> />/ wrote: />/ On Sunday 29 July 2007 08:47:50 Maciej Stachowiak wrote: />/ > On Jul 28, 2007, at 3:52 AM, Lars Knoll wrote: />/ > > On Saturday 28 July 2007 00:26:19 Maciej Stachowiak wrote: />/ > >> On Jul 27, 2007, at 11:36 AM, Lars Knoll wrote: />/ > >> />/ > >> Other organizations have requested the ability to use other XML />/ > >> parsers as well, such as expat. Seems like in the long run we />/ want a />/ > >> different approach than just ifdefs in the XMLTokenizer.cpp />/ file. It />/ > >> seems like the best would be some abstraction layer on top of the />/ > >> parser library, but if that is difficult then your option #2 />/ sounds />/ > >> like a docent long-run approach. I would have expected just about />/ > >> every XML parsing library to have a SAX-like API, which />/ shouldn't be />/ > >> too hard to abstract, but perhaps QXml works differently. />/ > > />/ > > I guess that assumption doesn't hold. QXmlStream is a streaming />/ > > parser with an />/ > > API that is very different from SAX. It IMO a whole lot simpler to />/ > > use than a />/ > > SAX like API and is inspired from similar APIs in the Java />/ world. If />/ > > you're />/ > > interested, have a look at />/ > > http://doc.trolltech.com/4.3/qxmlstreamreader.html />/ > />/ > I'm told libxml has a StreamReader-style API now as well, so if />/ that's />/ > the better alternative, we could design the XML code around that />/ style />/ > of API (though probably not right at the moment). />/ />/ No, for the moment, I'd rather just go with the approach I've posted />/ in bug />/ 14791. Once there are requests for more parser backends, we could />/ rethink />/ this, but for now I think we have more urgent things to do. />/ />/ Cheers, />/ Lars / _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev