cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <>
Subject Re: TRAX: suggested revised examples
Date Wed, 16 Feb 2000 19:56:56 GMT
I don't see why we should use XMLFilter per se. It's simply a way to
hook two ContentHandler's together with special semantics (i.e. calling
parse()). An XSLT transformer might have a similar interface but let go
of the parse() method call. An XSLT transformer will end up having other
semantics as well (e.g. the transformation context).


Kay Michael wrote:
> > Mike, I'm off traveling for a couple of days, and will have relatively
> > little access to email and fairly little time to work on
> > this.
> I've got deadlines this week so I haven't been able to apply much thought to
> it.
> I have come round to Scott's idea that a transform object should be a SAX2
> XMLFilter. My problems with this interface were (and are) all to do with the
> parse() method that gets the filter going: (a) it assumes that at the source
> of the pipeline there is an XMLReader and an InputSource encapsulating a
> serial file, and (b) it assumes that the process will be started by someone
> at the sink of the pipeline saying parse() and this triggering all the way
> up to the source. Those assumptions prevent a pipeline that forks, such as
> we need for multiple output documents, and it also makes it very hard to
> structure the code if one stage of the pipeline wants to control what the
> downstream stage should do, which is the typical structure with xsl:output.
> But XMLFilter implements ContentHandler, and if it's a ContentHandler then
> it must expect its StartDocument() event to be called at any time, whether
> or not it has called parse() to ask for it. It seems to be perfectly
> possible to use an XMLFilter without parse() ever being called, so it seems
> it should work in either push or pull mode.
> The main weakness seems to be in the helper class, XMLFilterImpl, rather
> than in the XMLFilter interface itself. I would expect a call of
> setParent(x) to cause x.setContentHandler(this), but it doesnt; the parent
> is only told to send output to the child at the time parse() is called. An
> unsolicited call of startDocument() on the parent will therefore fail.
> So the conclusion is that we can build a pipeline out of XMLFilter objects,
> and push data down it, without having to receive a parse() call from the
> downstream end, provided that we don't rely on the logic of XMLFilterImpl.
> In particular, it is legitimate to write a different implementation of
> XMLFilter in which parse() on the uppermost filter in the pipeline pushes
> the events down the line. It's also legitimate for the process to be started
> by a call other than parse(InputSource), for example it could be started by
> copy(Node); there doesn't need to be an InputSource present, which solves
> our problem if there is no serial file to be parsed.
> I think we should also extend XMLFilter to ensure comments are passed down
> the line. I don't really like the idea of testing to see whether the
> recipient implements LexicalHandler.
> If David Megginson is listening, I'd be interested in your views!
> Mike Kay

Assaf Arkin                                 
CTO, Exoffice Technologies, Inc.              

View raw message