XML Component API

[Oren Ben-Kiki]

Bill la Forge wrote:

>The emphasis of MDSAX is to construct a process with a set of filters which
share
>a common state. Note that this is quite distinct from the movement of
events and/or
>DOM Document objects between different document processors (still in the
same
>runtime).

I'm not quite certain that this distinction is as strong as you make it. The
API that I suggested is meant for independent processing components, that's
true, but I don't see why one can't simply give each component a reference
to a shared state object. For common tasks (e.g.,
full-standard-XML-processing) this state object could provide a standard
interface (such as an element stack).

This leaves the issue of setting up the set of components to achieve the
desired task - I understand that MDSAX helps in this regard, while my API
requires the programmer explicitly connect the pieces. I'd like to see just
how MDSAX achieves this.

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

Could you give an example of combining components within MDSAX which
couldn't be done easily/reasonably using my API with shared state objects?

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