cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Boag/CAM/Lotus" <>
Subject RE: SAT API Proposal (Draft 3) (was XSLT API)
Date Thu, 10 Feb 2000 18:11:47 GMT

> Kay Michael <> wrote:
> I'm confused by your chaining example

Yes, I guess I was confused too!

>     transform3.setContentHandler(serializer.asContentHandler());
>    transform3.setParent(transform2);
>    transform2.setParent(transform1);
>    transform3.parse(new InputSource("foo.xml"));

Um, I think it should actually be:

    transform1.parse(new InputSource("foo.xml"));

t1 acts as the parser, which feeds into t2, which feeds into t3, which
feeds into the serializer which feeds to system.out.

> We
> really want a "push" pipeline, whereas XMLFilter gives us a "pull" model.

I think it's important to tie into SAX2s idea of chaining processes.  But
the push pipeline is also useful.

> But this seems strange, and is especially strange if the first thing in
> pipeline is not a real parser

It's the equivalent.

> Since we're doing a "push" into the serializer, perhaps we should use the
> same mechanism to push events from one transformation into the next, and
> from the user's application into the first transformation:
>     transform3.setContentHandler(serializer.asContentHandler());
>     transform2.setContentHandler(transform3);
>     transform1.setContentHandler(transform2);
>     application.setContentHandler(transform1);

I was trying to avoid having the Transformation interface also be a
ContentHandler, since it now extends XMLReader, which I still feel is the
right thing.  Also, it was seeming from the replies on the list that having
a Tranformation also be a Content handler was somewhat confusing.  I guess
we need a asContentHandler method for Transformation now for the "push"
model, which would be consistent with the Serializer method.


How's that look?  This way we can support both push and pull.

> That then raises the question about whether a ContentHandler is good
> what about events like comments that a ContentHandler doesn't handle? My
> view would be to define a SATEventHandler interface that extends
> ContentHandler, DTDHandler, and LexicalHandler,

I don't see why we need to pass in as a aggregated interface, and I don't
think we should invent things unless we absolutely have to.  The
Transformation can just ask for a LexicalHandler interface from the
ContentHandler, or not send comment events if it can't get it.

> and to define SATFilter
> modeled on XMLFilter but (a) extending SATEventHandler instead of the
> SAX2 handler interfaces, and (b) working on a push model rather than

We should try very hard to be consistent with SAX2's model of the world
where it makes sense.  I don't think this will put a great burden on the

> Finally, the remark about multiple outputs raises the question as to
> setContentHandler() really belongs on Transformation at all.

Every stylesheet starts with a single input and a single output.  The fact
that you add more inputs and more outputs within the stylesheet shouldn't
effect the API interface, IMHO.

> We already have
> it on Result, which seems a more natural place: presumably there will be
> Result for each output tree, once multiple outputs are in the XSLT spec.

At this point, maybe we should do away with the result object, or morph it
a bit.  I think OutputProperties/Serializer takes care of everything the
Result object ought to do.   You could just have:

  public void process( InputSource xmlSource, Node node);
  public void process( InputSource xmlSource, OutputStream byteStream);

I would -really- like this, partly for the reason that it would stop people
from asking why Result isn't an interface.


View raw message