Lists Home |
Date Index |
- From: Tyler Baker <email@example.com>
- To: Michael.Kay@icl.com
- Date: Mon, 18 Jan 1999 18:38:15 -0500
> > From: Oren Ben-Kiki [mailto:firstname.lastname@example.org]
> > I raised the question of a standard API to XSL processors in
> > the XSL mailing
> > list. This question has quickly touched on general issues of
> > how to combine
> > XML processing modules, since there are two incompatible ways
> > to pass XML
> > data - as an in-memory DOM tree or as "parsing" events.
> SAXON (http://home.iclweb.com/icl2/mhkay/saxon.html) provides a higher-level
> API that can be used to process XML documents on top of either SAX or DOM.
> It provides a useful model where most of your processing is sequential but
> you might occasionally (or in the future) want to navigate from a node that
> you reached serially, e.g. to follow an IDREF.
> I've recently been trying to implement an XSL subset using SAXON and have
> realised that the XSL processing model requires the document to be built in
> memory, even though 90% of useful applications don't. For an XSL API,
> therefore, I think you can forget any idea of an event-based approach.
> Mike Kay
That has not been my experience. I have not had any problem with spitting out
processed XSL Output to SAX events. Things could change, but for now I have not
found any reason why you can't use DocumentHandler as an interface for delegating
processing of XSL output.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)