OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: XML Component API

[ Lists Home | Date Index | Thread Index ]
  • From: "Bill la Forge" <b.laforge@jxml.com>
  • To: <Michael.Kay@icl.com>, <xml-dev@ic.ac.uk>, "Oren Ben-Kiki" <oren@capella.co.il>
  • Date: Wed, 20 Jan 1999 01:05:54 -0500

The focus of MDSAX is to enable the processing of multiple document
types, each type being handled a little differently. This would be a document processing

There could be different kinds of document processors, implemented with different
classes, all in the same runtime.

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 

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.

Mike, I hope you don't give up on trying to understand MDSAX. Our plan is to start
working on the api documentation now and to develop the next level of detail on the
web pages in February.

As we make this more understandable, I expect that we be getting more suggestions
from the XML community on how to make it more useful. For now, its pretty hard to
participate in the design process, but changing that is our current priority.

Right now I'm working with Paul Rabin to help bring him up-to-speed on MDSAX. The
first consequence of that was a change to a lot of the class names, as well as a clean up
on how the ElementFilter worked. But I think the result has made it easier to understand.


-----Original Message-----
From: Michael.Kay@icl.com <Michael.Kay@icl.com>
To: xml-dev@ic.ac.uk <xml-dev@ic.ac.uk>
Date: Tuesday, January 19, 1999 4:39 AM
Subject: RE: XML Component API

>> The SAXON framework seems well suited for doing XSL-like 
>> transformations,
>> but doesn't solve the problem of combining different XML processing
>> components into a single computation - at least, it doesn't 
>> seem to have
>> have any advantage over the SAX interfaces in this very 
>> specific regard.
>You're right: I've been struggling this week trying to implement stylesheets
>using SAXON, which requires multiple XML processing components, and it's not
>easy. SAXON is good at producing multiple outputs from one input, but
>multiple inputs (files or views) is more difficult. If anyone has any
>suggestions, please let me know! I've started looking at MDSAX to see if
>that offers any inspiration: perhaps it will, when I understand it better.
>Mike Kay
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
>To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
>(un)subscribe xml-dev
>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS