"Peter B. West" wrote: > I have not have the chance to do that yet, and I want to look at it in > the context of actual FOP parsing, becuase I expect that there will be a > significant hit. The cost of this will have to be viewed in the context > of the intensive down-stream processing of FOP, so I am hoping the > relative penalties will not be excessive.
hi Peter, that is exactly main design objective of XmlPull API - allows creation of very efficient implementations (that are also easy to use - it took us some time to experiment with it and multiple different APIs before like XPP1, XPP2 and kXML1 ...) > The benefit is the revolutionary impact on system design from enabling > top-down pull processing. i think that in many cases when you process XML document pull parsing makes life much easier :-) > Andy has contacted me and referred me to nekopull, which I am having a > look at. Andy's design has many similarities to what I have done, > except that is is much more general and XML feature complete. For FOP I > implement a synchronized circular buffer to restrict buffer costs, and > to prevent the parser from running away from the downstream processing. XPP3/MXP1 and kXML2 works by tokenizing XML directly and reading only what is needed to return XML events to application as soon as they are available. the problem with XNI in Xerces2 and buffering is related to the fact (as far as i understand Andy explanations) that currently in XNI pull parsing mode there is no guarantee on number of XNI callbacks generated so pull parser must buffer content of callbacks as there may be more then one callback between each call to XMLPullParserConfiguration.parse(false) (parseSome() would be better name for this functionality instead of parse(false) ...) > At the moment my basic interface to SAX is a get() which returns an > XMLEvent which amalgamates the SAX information in which I am interested > - event type, attributes, uri, localName, qName, characters. I am > interested to see if I can implement an on-demand getEvent() call which > returns something comparable. you can very easily create it in XmlPull API and as XmlPullParser does not require any event object (so not forcing on you what is best XMLEvent) you can pick what you need from XmlPullParser and put it into your XML event object that is best suited for your application. > On top of that method, and in association > with a single-entry pushback buffer, I can build get and expect methods > of increasing complexity. Get finds the next event matching the event > parameters, discarding intervening events, and expect returns the next > event if it matches the requested event or one of the set of requested > events. Expect has a whitespace-handling parameter. that is main advantage of XML pull parsing: how easy is to build more complex parsing functionality by combining lower level parsing functions. > The question is, do the facilities exist for me to be able to do this > with XNI, or is more work required at a low level before I can configure > such a parser? please check XNI2XmlPull (see CVS at http://sourceforge.net/projects/xni2xmlpull/) and you may find X2Iterator to be useful wrapper to deal with XNI parse(false) functionality as it it converts XNI call-backs into internal events and put them into queue and it does all that possible to minimize memory allocations by reusing queue slots. hope you find it useful. thanks, alek -- The ancestor of every action is a thought. - Ralph Waldo Emerson --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
