SAX Future

[Michael Kay]

>> 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 at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)