Possible, but not easy. For example, xsl:copy-of is traced as one instruction, and it's not obvious from the trace call whether it outputs an element node, so it's not obvious whether an element node that's subsequently emitted derives from this instruction.
 
Michael Kay


From: saxon-help-admin@lists.sourceforge.net [mailto:saxon-help-admin@lists.sourceforge.net] On Behalf Of ROSSEL Olivier (CIMPA)
Sent: 14 April 2004 14:52
To: 'saxon-help@lists.sourceforge.net'
Subject: RE: [saxon] Tracing a transformation

The only constraint with "back mapping" is that buffering step?
Then Saxon could be hacked to trace events just before the buffering step.
 
Then it would be easy to deduce an accurate mapping.
The only drawback would be that attributes (and probably namespace too)
would sometimes be traced much after the startelement()
(which is not a problem if your only concern is the "back mapping").
 
-----Message d'origine-----
De : Michael Kay [mailto:mhk@mhk.me.uk]
Envoyé : mercredi 14 avril 2004 16:19
À : saxon-help@lists.sourceforge.net
Objet : RE: [saxon] Tracing a transformation

NO, the buffering is done regardless of the output method.
 
The Stylus Studio debugger uses some tricks to achieve its "back mapping" where it links elements in the result file to the instruction that created them; this is based on some pretty hairy analysis of the Saxon internals.
 
Michael Kay


From: saxon-help-admin@lists.sourceforge.net [mailto:saxon-help-admin@lists.sourceforge.net] On Behalf Of ROSSEL Olivier (CIMPA)
Sent: 14 April 2004 13:35
To: 'saxon-help@lists.sourceforge.net'
Subject: RE: [saxon] Tracing a transformation

Do you see any trick to achieve "XSL instructions tracing" with Saxon?
Does the building of a *DOM* result also contain some buffering step? Or is it more straightforward?