Cart
[Home] [By Thread] [By Date] [Recent Entries]
>> 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...)
|
