SAX2: ParserFactory

Leigh Dodds ldodds at
Thu Jan 13 14:30:56 GMT 2000

Miles Sabin wrote:
> An XMLReaderFactory could return an Iterator or Enumeration over
> the available implementation classes (more likely over some
> meta-information providing access to the features of the
> various installed parsers so an application can choose if
> there's more than one) and allow an app to select and
> instantiate one.

Why not have the Factory method accept the criteria, 
and return an implementation directly, rather than forcing 
the application to iterate over them?

In the case where there are several parsers with the same
properties, it will either matter to the application - in which the 
preference will be hard-coded (not good) as it will have to select 
it from the list, or it won't matter, so returning the 
first match is good enough.

If there are two parsers with the exact same features its likely 
that there will be other differentiators which can't be 
checked in code. e.g. which is the fastest. 

> The neat thing about this is that if we choose a well known
> location on the CLASSPATH to put the provider files it'll be
> possible to bundle a parser implementation along with it's
> own provider file.

Why not have the equivalent of a BeanInfo file for the parser.
Just add the package names to the XMLReaderFactory's property 
files and the properties can be checked at runtime. This 
seems less complex. Loading and parsing a file seems like more 
overhead than instantiating a BeanInfo equivalent and querying 
it directly.

Anyway, doesn't the JAXP package address some of these issues?



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions now closed in preparation for transfer to OASIS.

More information about the Xml-dev mailing list