Lists Home |
Date Index |
- From: "Michael Kay" <M.H.Kay@eng.icl.co.uk>
- To: "XML Developers' List" <firstname.lastname@example.org>
- Date: Wed, 18 Nov 1998 10:06:14 -0000
>> There are other version control nasties lurking in the "helper" classes.
>> 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
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
(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.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)