Fwd: Re: Pull parsing mode-- Is it implemented

[Jeffrey Rodriguez <je...@hotmail.com>]

Does Xerces-C implement pull parsing event mode?
Thanks,
                 Jeffrey Rodriguez

>>
>>Jeffrey Rodriguez wrote:
>> > I remember last year talks about providing a way to use the parser
>> > in a a Pull parsing event mode ( versus the pushing mode of the SAX
>>parser
>> > today).
>>
>>Which version of Xerces are you referring to? Both Xerces 1.x
>>and Xerces2 have implemented pull-parse capability but they
>>do it differently.
>>
>>In Xerces 1.x, there are methods on both parses that need to
>>be called to do pull parsing. First, you call parseSomeSetup
>>and then make repeated calls to parseSome to do the pull-
>>parsing. I don't quite recall how many methods are called per
>>call to the parseSome method but I think it's undetermined.
>>Also, the delivery of character events is short circuited in
>>the code. Therefore, the pull-parsing will not return until
>>all of the character content between markup is delivered.
>>
>>Xerces2 also has pull-parsing capability but the methods are
>>not immediately available through the parser. The reason for
>>this is that the parser classes that build DOM trees or emit
>>SAX events need to work generically with all kinds of parser
>>configurations which may or may not support pull-parsing. So
>>we have introduced an interface that descends from the parser
>>configuration interface and adds methods for pull-parsing.
>>
>>Since the standard Xerces2 scanner component can operate in
>>a step-by-step fashion, the StandardParserConfiguration
>>implements the XMLPullParserConfiguration interface. So you
>>can do pull-parsing (of a DOM tree) with the following code:
>>
>>     XMLPullParserConfiguration config =
>>         new StandardParserConfiguration();
>>     DOMParser parser = new DOMParser(config);
>>
>>     config.setInputSource(/* XMLInputSource */);
>>     while (config.parse(false)) {
>>         // do something
>>     }
>>
>>However, don't assume that each call to parse(false) has
>>a one-to-one relationship with how many XNI handler
>>methods are called. It may be zero or it may be many.
>>But the scanner *will* stop and return control to the
>>application at "reasonable" points. There are two reasons
>>why it's not one-to-one: 1) the implementation isn't
>>broken down enough to make sure that one and only one
>>XNI handler method is called per step; and 2) even if
>>we implemented the correct breakdown in the scanner,
>>later stages in the pipeline can generate additional
>>events (e.g. the namespace binder).
>>
>>Hope this helps.
>>
>>--
>>Andy Clark * IBM, TRL - Japan * andyc@apache.org
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
>>For additional commands, e-mail: xerces-j-user-help@xml.apache.org
>>
>
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
>For additional commands, e-mail: xerces-j-user-help@xml.apache.org
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org