Ted Leung wrote:
> As I said, I can live with this, but it does seem unclean,
> because the pull parser API shouldn't be exposed in the
> Configuration.
I'm still thinking that the parser configuration should
have the methods (just like the document and DTD scanner
interfaces have this ability). However, all configurations
are not required to be able to do pull-parsing. If the
configuration doesn't support it, then calling parse with
a value of false (in order to parse only the next bit of
the document) would do nothing.
If we end up not exposing the pull parsing through the
configuration interface (and possibly through the parser
implementations), then people can't take a generic
configuration and perform pull parsing for the existing
DOM and SAX parsers. Then we're back in the situation we
had before when we didn't have scanner interfaces: people
could build configurations but never *start* parsing them
in a generic way.
> Well, let's talk about this how this would work -- You'd have
> to return an object that that had say:
>
> public interface PullParserAPI {
> public void setInputSource (InputSource);
> public boolean parseDocument(boolean);
> }
Interesting. I still don't like the property object
because it can only be checked at run-time when you
want to know at compile-time that you have this
capability. Another option would be to extend the
XMLParserConfiguration interface. For example:
public interface XMLPullParserConfiguration
extends XMLParserConfiguration {
public void setInputSource(InputSource) throws ...;
public boolean parseDocument(boolean) throws ...;
}
Then if your configuration that you're using is an
instanceof XMLPullParserConfiguration, you know that
the configuration supports that capability.
--
Andy Clark * IBM, TRL - Japan * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
