+1 for both proposals.

Making all the pipelines dynamically configurable would make Xerces more
flexible. It also introduces chances to improve the performance: components
in the pipeline can be removed when not needed.

> can someone remind me of the use case that
> prompted us to break DTDHandler up like this?

I'm puzzled by the same question too.

Cheers,
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
[EMAIL PROTECTED]



                                                                                       
                                                
                      Neil                                                             
                                                
                      Graham/Toronto/IB        To:       [EMAIL PROTECTED]   
                                                
                      M@IBMCA                  cc:                                     
                                                
                                               Subject:  [PROPOSAL]:  minor XNI change 
                                                
                      11/19/2002 08:48                                                 
                                                
                      PM                                                               
                                                
                      Please respond to                                                
                                                
                      xerces-j-dev                                                     
                                                
                                                                                       
                                                
                                                                                       
                                                



Hi folks,

Seems I've forgotten some of the intricacies of XNI.  :)  I neglected to
take into account that, in addition to the XMLDTDSource/Handler interfaces,
we also have the XMLDTDContentModelSource/Handler interfaces.  So, if a
component is to be able to reconfigure the DTD pipeline, it also needs to
re able to reconfigure this aspect.

So I need to amend my original proposal to add

      public XMLDTDContentModelHandler getDTDContentModelHandler();

to the XMLDTDContentModelSource interface, and

      public void setDTDContentModelSource(XMLDTDContentModelSource
source);

      public XMLDTDContentModelSource getDTDContentModelSource();

to XMLDTDContentModelHandler.

Now I don't mind doing this, but can someone remind me of the use case that
prompted us to break DTDHandler up like this?  Throughout our own code the
same classes always implement both interfaces; was there some application
that needed one but not the other?

Anyway, all thoughts appreciated!

Cheers,
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone:  905-413-3519, T/L 969-3519
E-mail:  [EMAIL PROTECTED]


----- Forwarded by Neil Graham/Toronto/IBM on 11/19/2002 08:41 PM -----
|---------+---------------------------->
|         |           Neil Graham      |
|         |                            |
|         |           11/19/2002 10:09 |
|         |           AM               |
|         |                            |
|---------+---------------------------->
  >
---------------------------------------------------------------------------------------------------------------------------------------------|

  |
|
  |       To:       [EMAIL PROTECTED]
|
  |       cc:
|
  |       From:     Neil Graham/Toronto/IBM@IBMCA
|
  |       Subject:  [PROPOSAL]:  minor XNI change
|
  |
|
  |
|
  >
---------------------------------------------------------------------------------------------------------------------------------------------|




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:  [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]

Reply via email to