ModSAX: Proposed Core Features

[Oren Ben-Kiki]

Bill la Forge <b.laforge at jxml.com> wrote:

>If ModSAX is to remain low-level, I suspect a registry is out of scope. As
for building
>up a parser with filters to meet a set of requirements automagically, I'd
rather give
>more control to the application to specify what it needs, than try to
compose
>something based on a feature list.


A registry might be outside the scope of ModSAX (but see below). Even if it
is, I feel that we should take care that ModSAX design choices won't make
such a registry unnecessarily difficult. It might also be that a "registry"
is the wrong way to go; John Cowan, for example, suggested a mechanism to
allow a parser to automatically push a filter between itself and the
application. I'm certain there are other reasonable approaches.

All I'm saying is that before we decide on ModSAX, some thought should be
given to this issue.

To get the ball rolling, how about the following low level solution, which
would allow smarter high level solutions later on:

class ModSAXRegistry {
    static void setClassFeatures(String className, String[] featureNames);
    static String[] getClassFeatures(String className);
    static Enumeration getFeatureClasses(String featureName);
    static Object newInstance(String className);
}

The idea being that it would be easy to get a list of classes which provide
any requested feature, and check which features are implemented by a
particular class. This should be trivial to implement; static code could do
the registration automatically, or it could be loaded from property files,
environment variables, or whatever.

We already have one standard feature: "org.xml.sax.parser", to which we
should probably add "org.xml.sax.filter".

The question of how to build a parser implementing a particular feature
would be left open. In general the application would query the registry, use
whatever algorithm it likes to decide on which classes to use, instantiated
them and go on as per the current ModSAX interface.

Once enough experience is gained using this, we could decide to add some
methods which implement popular algorithms.

Compatibility with the current state: It should be trivial to implement
ParserFactory above the registry. As for property files, the following
scheme is safe and upward compatible with today's practice of providing the
SAX parser name in "org.xml.sax.parser":

org.xml.sax.class.<class-name>=<feature>,<feature>,...
<feature>=<default-class-name>

The whole thing is as lightweight and low-level as you can get.

Share & Enjoy,

    Oren Ben-Kiki


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/ and on CD-ROM/ISBN 981-02-3594-1
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)