xml-commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Glavassevich <mrgla...@ca.ibm.com>
Subject Re: Comments on the Xerces portions on the JAXP 1.3 donation
Date Tue, 26 Apr 2005 18:34:33 GMT
Hello Neeraj,

The semantics of the JAXP 1.3 reset and the XNI component reset are very 
different from each other. While the JAXP reset() sets the parser instance 
back to its factory settings, the XNI component reset() gives a component 
an opportunity to initialize itself as well as read features and 
properties from the configuration. The configuration calls reset() on each 
component when the pipeline is being configured on each parse, so it isn't 
evident to me why it would need to be called during JAXP reset(). If the 
values of any features/properties changed as a result of resetting back to 
the factory settings, then each component gets a chance to read them the 
next time the application calls parse().


Neeraj Bajaj <Neeraj.Bajaj@Sun.COM> wrote on 04/21/2005 08:11:03 AM:


> >I also noticed that the JAXP SAXParser and DocumentBuilder now fix the 
> >XMLParserConfiguration to a new configuration called JAXPConfiguration. 

> >Previously it was possible to override [1] the parser configuration, a 
> >rather powerful feature that's been supported throughout Xerces2 
> >In addition to the many parser configurations [2] which ship with 
> >other applications such as NekoHTML provide parser configurations which 

> >can be used to override the default parser configuration. It isn't 
> >to me why the parser configuration would need to be fixed. Was there a 
> >compelling reason for doing this?
> >
> > 
> >
> IIRC, this was something to do with changes related to newly introduced
> function reset() in SAXParser & DocumentBuilder. reset() sets the 
> back to factory settings. A parser configuration can't reset() itself. 
> Say if a
> configuration contains n components there isn't any function which 
> all components to be reset. Neither it has any function to know what all
> components are part of it.
> I think there might be other solution to this problem, may be we just 
> to put more thought on this.


> -Neeraj

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

View raw message