[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML Component API

• From: "Bill la Forge" <b.laforge@j...>
• To: <Michael.Kay@i...>, <xml-dev@i...>, "Oren Ben-Kiki" <oren@c...>
• 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
object.

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

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.

Bill

-----Original Message-----
From: Michael.Kay@i... <Michael.Kay@i...>
To: xml-dev@i... <xml-dev@i...>
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@i...
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
>To (un)subscribe, mailto:majordomo@i... the following message;
>(un)subscribe xml-dev
>To subscribe to the digests, mailto:majordomo@i... the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa@i...)
>


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

• Prev by Date: XML EDI career question
• Next by Date: Re: Ptr to Fast Well-Formed XML parser (Java)? (C-expat)
• Previous by thread: RE: XML Component API
• Next by thread: Re: XML Component API
• Index(es):
  • Date
  • Thread