ModSAX: Proposed Core Features

[Ronald Bourret]

Oren Ben-Kiki wrote:

> >* What are the interfaces between components and how hard are they to
> >implement?
>
> Basically the SAX callbacks, probably extended so that the full document
> data is available (comments and so on). This seems pretty much a done 
deal.

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", 
and
> provide a simple, lightweight, low-level API which allows it to do so. 
More
> complex solutions could evolve later on. This seems to be in the SAX 
spirit.

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 
parsers.

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;
(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)