[xslt] Debugging large stylesheets with xsldbg

[k_isdale tpg com au]

Hi all,

I been running xsldbg over docbook.xsl. With no 
breakpoints set it it ran well with only small 
impact on the execution time of the docbook 
stylesheet(s). I found a bug in the finding of 
templates. xsldbg currently looks only at the 
topmost stylesheet for template names. This is 
being fixed.

Also I found some unintentional assumptions I  
made :-( . 
  1) Assumed that the root template specfied 
would be executed at some point
  2) Assumed the user would know what the 
template names that could be used for the root 
template
  3) Assumed there would be a reasonable number 
of variables, templates and stylesheet files
  4) There would only a few breakpoints set at 
any time. This was wrong because docbook.xsl have 
over 500 templates and I allow the user to set 
breakpoints on all templates! 


Problem 1) 
 Solution: I've added a new function that allow 
the xsldbg.c know if any breakpoints have been 
found at all. If not then breakpoints are set on 
all templates found for the next attempt of 
debugging.

/** 
 * xslDebuggerReached :
 * @reached : true if debugger has received 
control
 *
 * Set flag that debugger has received control to 
value of @reached
 * returns true if any breakpoint was reached 
previously
 */
int xslDebuggerReached(int reached);


Problem 2)
  Solution  If the root template is not found 
then I print out a list of template names and the 
program aborts.


Problem 3)
 Solution : Add ability to print the names of 
matching a query of template names, global 
variables names, stylesheet file names. I think 
this could be added at a later time, and should 
be a module by itself breakpoints/search.[ch].  
But if anyone has time to look at this great. I 
imagine this could be done by writing functions 
to walk though the list of all; template names, 
variables names, stylesheet file names (mostly 
just wrappers over existing hash table 
functions ).

Problem 4)
 Solution : Change data structure of used by 
breakpoints to a linked list. This would put no 
restrictions on the number of breakpoints that 
could be set. 

Question : Is performance an issue for debugging ?
If so would making a breakpoint hash table might 
be a better solution . Where the "key" for each 
entry in the hash table is calculated by a strcat 
of the string version of the line number and 
stylesheet url. This would mean that for before 
every statement executed the "key" for that 
statement woukd need to be calculate and then 
looked up in the breakpoint hash table. This 
solution would increase the complexity of the 
breakpoint API and increase the probability of 
bugs :(

It would be much appreciate for people to give 
feedback on xsldbg /comment on the breakpoint 
API. It's hard to find bugs in your own 
interfaces/code.

It my intention to make this a valuable tool in 
its own right. Not just a means to step though 
xml/xsl code. 

Comments?

ps: There's a explanation of what is needed to 
create GNOME docbook xml at 
http://www.math.sunysb.edu/~kirillov/dbxml/index.h
tml

Daniel: Have you got list of the interfaces for 
the functions being exported out of xsltproc. Or 
a mockup of what you have in mind.

bye,

Keith