Lists Home |
Date Index |
- From: Tyler Baker <email@example.com>
- To: Michael.Kay@icl.com
- Date: Wed, 27 Jan 1999 12:38:55 -0500
> Tyler Baker:
> > To make this work you would need to do several things:
> > (1) Change the ParserFactory class to not return a parser but
> > a ParserGenerator
> > object (in this case you might want to change the name
> > "ParserFactory" to "ParserGeneratorFactory").
> I do think it would be useful for SAX to include a helper class for parser
> selection. This proposal, though, seems a little too abstract for most users
> to stomach (like telling someone who wants to watch News at Ten that he
> needs to start by instantiating a television factory generator). I'd suggest
> something more along the lines of the ParserManager in SAXON (which was
> inspired by the ODBC Driver Manager). It currently:
I kind of agree here. Sometimes you just have to throw enough stuff at the wall
and see what sticks. I guess this idea may not be sticking (-:
> - maintains a list of available parsers, known by familiar product names
> (e.g. "xp", "oracle")
> - maintains a preference order
> - allows an application to load a parser, scanning the preference list till
> it finds one suitable.
> I've considered for a long time maintaining separate lists of validating and
> non-validating parsers so you could choose one from either list: one could
> extend this idea to selecting a parser based on all its properties. The
> "parser" could also be a composite consisting of a parser plus one or more
Seems like a good idea.
> We could then have a simple (static) interface
> ParserManager.loadParser(properties) that returns a parser matching the
> stated application requirements.
This would allow people to extend SAX and provide optional support for features
in the future that we can't really predict at this time without cluttering up the
> There could also be an interface allowing parsers to register themselves:
> ParserManager.registerParser(this); this would call back to get information
> about the parser's properties.
> I think users could cope with that.
Seems pretty simple and straightforward to me.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)