Elena Litani wrote: >>And even if we agreed that it was worth the >>damage, your change then requires all parser >>configurations to have a NamespaceContext object >>in their configuration. Here begins the slippery >>slope... > > Well, this is what we do for SymbolTable. The basic parser configuration > always sets SymbolTable and NamespaceContext properties so a > configuration that extends the basic one does not need to do anything > specific.
The framework is separate from the Xerces2 implementation of that framework. I have written (and will continue to write) parser configurations that use the framework but stand on their own (i.e. they don't use Xerces2 components). In that situation, why should I have to create an extra object just so that I can plug into the API-generators (e.g. DOMParser, SAXParser, etc.) that use my parser configuration? I think this change (for such a small performance gain) is detrimental to the framework as a whole. And I would be against any change that introduces implicit requirements for users implementing the framework. I believe that this is the "accident waiting to happen" that Joe was talking about. -- Andy Clark * [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
