>> I'm looking for pointers/suggestions/best practices for producing a transformation-quality
>> result document alongside the transformed document.


> The information you need *is* accessible internally from the context - each
> XPathContext object is chained to the XPathContext object of its caller, so
> you can crawl your way down the stack, for example you can determine the
> context item at every level of call, and the local variables at every level
> of call. This was introduced relatively recently to support debuggers. The
> data isn't available without using extensions, and some of it is quite hard
> to interpret even with extensions - for example parameters to a function
> call are passed positionally rather than by name. You're a little exposed to
> things like tail call optimization which means that the internal call stack
> may not reflect exactly what you wrote in the source code, and of course you
> are using internal interfaces that can't be guaranteed stable from one
> release to the next.

I'd like to give this a shot.  If I understand correctly, adding the extra first argument
XPathContext to an extension function gives it a handle on all of the info
that I'm looking for (tunnel parameters, current context full path).

It seems to me that the nicest way of handling this would be to
have the extension function collect the information from XPathContext
and then call an XSLT template to add the info to the result document.
Is this possible?  Or is there a better way? 

Is there a good example that a novice can use for inspiration?


> Another way of tackling this kind of problem is to write the log data to the
> principal result document, perhaps in its own namespace, and strip it out in
> a post-processing phase. This would be the natural way to go if you are
> already using a pipeline architecture.

I particularly like this idea which answers the next question that I was going to ask.

Thanks for the help and any pointers to examples for newcomers.

-alan