Lists Home |
Date Index |
- From: "Oren Ben-Kiki" <firstname.lastname@example.org>
- To: "XML List" <email@example.com>
- Date: Wed, 20 Jan 1999 12:13:51 +0200
Bill la Forge wrote:
>The emphasis of MDSAX is to construct a process with a set of filters which
>a common state. Note that this is quite distinct from the movement of
>DOM Document objects between different document processors (still in the
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
>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,
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)