[EMAIL PROTECTED] wrote:
But the DTD pipeline isn't modifiable in the same way.
So I'd like to propose modifying XMLDTDSource and XMLDTDHandler in
much the
same way as XMLDocumentSource and XMLDocumentHandler were already
modified.
Since we're talking about the changes we want
to make in an attempt to finalize XNI, we should
do everything we can to make sure that we make
the right choices. So I would like to discuss
this more before we make additional changes.
In a previous release we made a change to the
XMLDocumentHandler to add a "setDocumentSource"
method. I was not initially in favor of this
change but relented because we had a definite
need to be able to dynamically modify the parsing
pipeline to increase performance. However, now in
hindsight, I think we may have made the wrong
change to get the desired affect.
Let's step back and look at the pipeline again.
We have a source of XML events, zero or more
filters, and a registered document handler which
is the final destination of events. This final
destination is either the application (if it is
written directly to XNI) or the various API
generators we have (e.g. DOMParser, SAXParser).
So far, so good.
Now, when someone wants to dynamically alter the
pipeline, what is actually modified? Isn't it
the arrangement of the filters in the middle of
the pipeline? So shouldn't the "setDocumentSource"
method be on the XMLDocumentFilter interface
instead?
It seems to me that we would still be able to
dynamically re-order the pipeline and keep the
interfaces cleaner this way. Can anyone think
of a reason why this wouldn't work?
That is, add
public XMLDTDHandler getDTDHandler();
to XMLDTDSource and
I don't have a problem with adding a query method
to match the setter on this interface as well as
the XMLDTDContentModelSource interface. That would
fix the oversight.
Thoughts?
--
Andy Clark * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
