ModSAX: Proposed Core Features
rbourret at ito.tu-darmstadt.de
Thu Mar 11 18:03:04 GMT 1999
Oren Ben-Kiki wrote:
> >* What are the interfaces between components and how hard are they to
> Basically the SAX callbacks, probably extended so that the full document
> data is available (comments and so on). This seems pretty much a done
and also wrote:
> >* Who assembles the components -- the application, the processor, or a
> >third party?
> What I'm suggesting is we currently answer "for now, the application",
> provide a simple, lightweight, low-level API which allows it to do so.
> complex solutions could evolve later on. This seems to be in the SAX
If the application assembles the components and the interface between them
is SAX, what do we need that SAX filters don't already give us? In other
words, does anything need to be done to OpenSAX (best name so far) to
support this besides adding the ParserFilter interface?
The other question that occurs to me is how useful/common it is to
dynamically assemble a processor at run time. That is, are there really
applications (outside of test environments) that allow the user to
designate their parser at run time (or even installation time) and
therefore need to cover any possible deficiencies in the chosen parser?
What is gained by allowing the user to choose the parser?
Note that this is a very different situation from, say, using different
ODBC drivers. In the case of ODBC drivers, you are choosing a different
source of data (type of database) and application writers have a strong
incentive to support multiple databases through ODBC. In the case of XML,
the source of data is always the same XML document and the choice of parser
becomes a trade-off between speed, reliability, feature-set, etc.
Since the application writer knows the feature set ahead of time, why not
just hard-code the required parser and SAX filters and be done with it?
(Yes, I know that "hard-code" is a bad word and I shudder as a write it,
but I really am curious if anybody out there has a real-world application
that allows users to change parsers and what the benefits of this are
besides the ability to say, "Oh, look. I'm using a different parser.")
In this view, the utility of SAX is not the ability to change parsers at
run time, but to change them over time as reliability, speed, size, etc. of
the parsers change. It also means that application writers can learn a
single interface (SAX) and then choose parsers as they are appropriate to
the application without having to learn different interfaces for different
The ability to request features in OpenSAX allows the application to
request processor behavior, which is slightly different from assembling a
suitable parser. For example, if I have an application that doesn't need
validation, but I the parser I want to use does validation by default, I
would like to be able to turn that off.
Just to be clear, I'm not necessarily against assembling processors based
on a feature set. I just believe that it is far more complex than it
appears at first glance and am not convinced that it's worth the trouble.
-- Ron Bourret
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;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev