[PROPOSAL]: minor XNI change

[ne...@ca.ibm.com]

Hi folks,

The main reason I've been quiet lately is that I've been working on a
prototype XML 1.1 implementation (look for a prototype in a week or so).
In order to avoid lots of version checks in the main-line code, or lots of
calls to super methods in the XML 1.1 code, I'm developing new Entity,
Document and DTD scanners, extending from the current implementations; I
want to use the current impls (unchanged as much as possible) on 1.0 docs,
the new ones on 1.1 docs.

One way to achieve this is to use a special scanner at the front of the
pipeline who's sole purpose is to figure out what kind of document the
parser is dealing with and then dispatch appropriate scanners to do the
actual scanning.  (This could also be done by a configuration, but since
this relies on rather intimate interactions with the entity manager and
existing scanners, this strikes me as highly unclean).

The changes Elena's already made to facilitate scanning/namespace binding
help, since they allow this new scanner to rework the document pipeline.
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.
That is, add

      public XMLDTDHandler getDTDHandler();

to XMLDTDSource and

      public void setDTDSource(XMLDTDSource source);

      public XMLDTDSource getDTDSource();

to XMLDTDHandler.

Thoughts?

Cheers,
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone:  905-413-3519, T/L 969-3519
E-mail:  neilg@ca.ibm.com



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

Re: [PROPOSAL]: minor XNI change

[Andy Clark <an...@apache.org>]

neilg@ca.ibm.com 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 * andyc@apache.org


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