It's a little hard to understand the limitations without access to the underlying ( hint hint ;), but why not implement some sort of lazy-evaluation for the pipeline elements.

You could construct a graph of the entire pipeline before evaluating any step. In this case, after the graph is constructed, you'd know to construct the view-ports, of the input document, before you loaded the stylesheet. Then, since you know the view-ports, you can register a "listener" for each of them to be fed the results of the pipe when it evaluates the stylesheet.

Thus you'd be able to only read from the pipe only once, and still be able to publish the stylesheet to all of the view-ports to transformation engine.

Then again, this might require the entire n-elemenets of the view-port list to be in memory, as opposed to resetting the pipe n times. It seems like it might be an either/or implementation decision or addition to standard.

There might be a way to hook up everything so that the events just "flow" once, but I can't think of a concrete example.

Thoughts?

Oh, and keep the implementation articles coming!

Thanks for the interest, Scott. I do have the whole graph before I begin. I think there's lots of room for interesting optimizations at that stage, but (1) I know I'll need to think hard about that when I get to trying to implement threads, so I'm not spending a lot of time thinking about it now, and (2) I'm trying to get something complete before worry too much about getting something that's necessarily fast, so I'm picking the easiest solution that will get the job done in every case.