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

Re: SAX Future

• From: "Michael Kay" <M.H.Kay@e...>
• To: "XML Developers' List" <xml-dev@i...>
• Date: Wed, 18 Nov 1998 10:06:14 -0000

>> There are other version control nasties lurking in the "helper" classes.
For
>> example SUN's distribution includes a modified version of ParserFactory,
>
>That is, a configuration error is transparently recovered from.
>
In SUN's position I think I might well have done the same thing, as it
clearly makes their product easier to install and get working. However, as a
user, I don't find it very useful to have several identically-named
ParserFactory classes on my class path, and to worry about which one has
been loaded! SUN circumvented a deficiency in SAX, and we ought to fix it at
source.

The ParserFactory in SAX plays the same role as the Driver Manager in ODBC;
we can't have every driver come with its own driver manager, we must have a
single driver manager which is rich enough in capability to configure any
drivers you might want to install.

In my view a good ParserFactory will have a user interface allowing you to
install a parser and specify your choice of default; it will have persistent
storage to remember what parsers are installed and which one is the current
default; and it will have an API allowing you to discover which parsers are
installed, to ask questions about them, and to select one that meets your
requirements (using a friendly name chosen when it was installed). In turn
each Parser needs to come with installation-time code that registers the
parser with the ParserFactory, giving the user the option to make it the
default one.

(All this applies equally, of course, to DOM implementations).

I tried to meet some of these requirements with the ParserManager in SAXON.
It's not ideal: the user interface is to edit a properties file; the process
of registering a new parser is entirely manual; it doesn't allow you to
register attributes, e.g. which parsers are validating and which aren't. But
I think it's a start, and I've certainly found it useful in my own work.

Mike Kay


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

• Prev by Date: Re: How do XML NameSpace aware processors react to NS definations?
• Next by Date: XML test cases updated
• Previous by thread: RE: SAX Future
• Next by thread: Question about sending and receiving XML via ASP's
• Index(es):
  • Date
  • Thread