XML Component API

[Bill la Forge]

>>I would say that MDSAX and something like the api that Oren Ben-Kiki is
>working on,
>>because they work at a different granularity, are quite complimentary.
>
>I'd rather have a single API for connecting XML processors, which would work
>at both granularities, then one for "inside a document processor" and one
>for "combining document processors", unless there's a very good technical
>reason to separate the two. For all I care this single API might be based on
>MDSAX, if that's appropriate.


I don't think it is ever safe to ignore granularity and that APIs for different levels of
granularity should be free to develop in different directions.

I've seen proposals to the OMG which had URLs as separate CORBA objects,
with remote-access methods for fetching the various parts of the URL. 

Closer to home, I've heard from several sources the idea that DOM elements should
be implemented as CORBA objects, with support for independent retrieval/update.

A reverse form of this problem is the overly simple api used for UNIX processes, where
perhaps a richer and more flexible interface might have been helpful in the long run.
(Yes, MS windows goes too far, IMHO, in the other direction.)

With very low-level api, it is quite helpful if applications of the api can consist largely of
inline code, and if the overhead for handling the interface is low. Efficiency considerations
rule!

At a high-level api, the applications can always make use of lower-level components
to handle a heavy-weight interface. The real need is to be able to interconnect a wide range
of components.

When connecting various document processes, you want to be able to connect a document-
flow with a SAX event flow. And in connecting various sources and sinks, you may need
something like a UNIX pipe: a thread-safe event queue.

But at the lower level, within a process, you want to be able to extend a base-level
filter class and just add 10 lines of code to manipulate a specific type of event. And you
do not want any extraneous overhead whatsoever.

There is another consideration as well. Within an MDSAX-based process, it is reasonable
to mandate that all filters implement the DocumentHandler interface and that the glue
code for chaining various filters together always reside in a factory class which 
implements the MDFilterFactory interface.

But when interconnecting different processes, you want to allow for a much greater range
of implementations. There should not be a requirement that all the document processes
within a single runtime use MDSAX internally, only that they can serve as either a source
or sink for a document or a SAX event. You want a framework for this larger granularity
into which you can plug almost any kind of document processor. (And in this case, the
framework may be quite application-specific, though that doesn't preclude the development
of a toolkit to help with the task.)

Bill


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/
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)