From: [] On Behalf Of Alan Painter
Sent: 15 April 2005 16:47
Subject: [saxon] RE: Requesting Pointers/Suggestions for a producing a transformation quality document

>> 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). 
Yes. Passing the XPathContext to the extension function is the easy part. The harder part is interpreting the data structures that you find: for example, working out the allocation of slots to local variables in the stackframe, especially as these are a mixture of variables defined in the user-written source code and variables allocated by the optimizer. And as I mentioned, you're exposed to the changes made in Saxon from time to time. For example, one of the changes that will come in the next version is that when an expression is subject to delayed evaluation, the stackframe at the time evaluation finally occurs will only contain those variables that the expression actually references.
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?  
The best way to do this, given that you have Saxon-SA, is probably to pass the extension function an additional argument in the form saxon:function("some:callback"), where some:callback is a stylesheet function. This will match a Java argument declared as being of class com.saxonica.extra.FirstClassFunction, and you can then invoke this function and pass it parameters using its invoke() method. Using functions is cleaner than using templates because there are fewer dependencies on the context, and this mechanism supports a dynamic call interface that doesn't rely on static type checking of parameters.
Is there a good example that a novice can use for inspiration? 
I'm afraid you are trailblazing here.
Michael Kay 

> 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.