[webkit-dev] Wrapping XML parser API

[Paul Pedriana]

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
/