cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Michael <>
Subject RE: TRAX: suggested revised examples
Date Wed, 16 Feb 2000 18:35:42 GMT
> 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

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

View raw message