[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Why SAX needs namespace support

• From: Tyler Baker <tyler@i...>
• To: Michael.Kay@i...
• Date: Wed, 27 Jan 1999 12:38:55 -0500

Michael.Kay@i... wrote:

> 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
> filters.

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
interfaces.

> 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.

Tyler


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• References:
  • RE: Why SAX needs namespace support
    • From: Michael.Kay@i...

• Prev by Date: Re: Why SAX needs namespace support
• Next by Date: Specifying options in SAX
• Previous by thread: RE: Why SAX needs namespace support
• Next by thread: Re: Why SAX needs namespace support
• Index(es):
  • Date
  • Thread