ModSAX: Proposed Core Features

[Oren Ben-Kiki]

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

>On a more serious note,
>
>I think we need a new ParserFactory... ModParserFactory? XParserFactory?
>It should use ParserFactory to create a Parser and then check to see if the
new
>extension is supported. If not, it proceeds to wrap the parser so that it
looks
>like a ModParser.
>
>Note that this compatibility wrapper will effectively be a filter.


I think you've hit on something important here. The Mod/X/Xtra/E-Sax thread
has focused on "how to access extra functionality which is already available
within a particular SAX parser implementation". This might be the wrong
question to ask. Shouldn't it be "how to I obtain an instance of a SAX
parser which provides the features I need", instead?

This is a subtle but important shift of focus. Today one can obtain an
instance of a SAX parser by using the ParserFactory. Now suppose my
application needs an order of a namespace aware parser, character
normalization on the side, and don't spare the comments, please - how would
I go around creating such a thing?

Note that this issue contains the original one; one needs to be able to
access the extra features. But it goes beyond it. It might also help to
constrain some design choices. Take for example the issue of naming
features. Today ParserFactory uses the string "org.xml.sax.parser" as an
identifier for the feature "take an input source and convert it to SAX
events". The format of this particular string was chosen since it is usable
as a key in a properties file.

Wouldn't it be reasonable to say that whichever way
Mod/X/Xtra/E-ParserFactory works, it will use the same approach - that is,
use Java-like package names to identify features, so that it will be
possible to provide default implementations using property files? I know
this would be hard for the URI camp to swallow :-) but isn't it worth it?

As to the issue itself, the way I see it there is one major question to be
decided first. Are the extra features independent of each other?

If they aren't, we are in trouble. How do I know that pushing a filter
implementing feature X on top of a parser implementing feature Y doesn't
break that feature? What if one feature depends on another? Should there be
a way to describe the relationship between features? How?

At any rate, the goal should be some registry of "parsers" and "filters"
with an appropriate API so that it would be possible to ask for a certain
feature set and obtain a "parser" instance. IMVHO as far as this registry is
concerned, the basic SAX events interface and the input source interface
should be on equal ground with the other features. This could be a flexible
framework allowing to create processing chains such as using DOM as
input/output of the chain, making XSL processing a core "feature", and so
on.

Has anything similar been done in a different field, so we could reuse the
design lessons there? It seems like a pretty generic "stream processing"
problem.

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)