Hi again Andy,
I realize all those points are true, but I was wondering whether we ever
had any *use cases* which made use of the coarse-grained information only.
I agree that it's not all that costly, and I wasn't advocating changing
things at this point; I think modifying this part of XNI at this stage,
just for the case of simplifying things slightly, would be waay out of
line...
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:42 |
| | PM |
| | Please respond to|
| | xerces-j-dev |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: [PROPOSAL]: minor XNI change
|
|
|
|
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
[EMAIL PROTECTED] wrote:
> 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?
It's broken up so that users of the framework can
have the choice of what level of detail they want
from the DTD information. Even though in our impl
all the appropriate components implement both
interfaces, this doesn't mean that there won't be
other implementations (or even the XNI application)
that use only one of them.
Besides... It doesn't hurt breaking them up and
it keeps us from having method explosion on any
single interface.
--
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]
