Hi Andy,
Great to see you're back; it was getting lonely around here. :)
Anyway: Consider the position of a filter that might like to take itself
out of the document pipeline. As things currently stand, it assumes it
has an XMLDocumentSource on one end and an XMLDocumentHandler on the other;
setting the handler on its source and the source on its handler is all it
ever needs to do.
Now, if I get your proposal correctly, the filter has to do a check to see
whether it has an XMLDocumentHandler on one end, or an XMLDocumentFilter.
If the latter, it needs to set its source on it; otherwise, it can't.
It's not hard for me to imagine filters like this; our own XMLDTDValidator
often finds itself in just such a position. Do we really need this extra
complexity, and does it make things cleaner? Maybe it does; I have to
admit my views aren't terribly strong.
Cheers!
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
|---------+---------------------------->
| | Andy Clark |
| | <[EMAIL PROTECTED]|
| | > |
| | |
| | 11/21/2002 06:31 |
| | PM |
| | Please respond to|
| | xerces-j-dev |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: [PROPOSAL]: minor XNI change
|
|
|
|
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
[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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
