|
|
## What are the initial conditions and how are things set up?
|
|
|
|
|
|
Top-level parameters, variables and key declarations
|
|
|
|
|
|
They help to illuminate the functionality and sometimes the approach
|
|
|
|
|
|
These do not have to be placed at the start of the XSLT, but they generally are.
|
|
|
|
|
|
How is the stylesheet organized? Is there any order to the templates? Are templates and modes kept together?
|
|
|
|
|
|
Again, the order and organization is not determinative of anything even quality: a very well designed XSLT from the functional point of view may be badly or sloppily ordered, just as good code can be badly documented. But it can be indicative and useful to know.
|
|
|
|
|
|
## What are the entry point(s) for the XSLT?
|
|
|
|
|
|
There can be more than one.
|
|
|
|
|
|
Typically, however, there will be a template matching "/" or matching an element expected to be at the root (the "document element" called in some nomenclatures the "root element").
|
|
|
|
|
|
Identifying the entry point is important because there is where you start analyzing the tree traversal.
|
|
|
|
|
|
## Analyze the tree traversal
|
|
|
|
|
|
Pull? Templates in modes? Grouping? Templates not in modes? Always top down, or any funny stuff?
|
|
|
|
|
|
Look at xsl:apply-templates/@select and also scan for usage and purpose of xsl:for-each
|
|
|
|
|
|
## Examine source and result (again)
|
|
|
|
|
|
## Characterize xslt purpose and logic
|
|
|
|
|
|
### What is the purpose?
|
|
|
|
|
|
A straight mapping or down-conversion e.g. making HTML from rich XML?
|
|
|
|
|
|
Or any of several other species of stylesheet or transformation
|
|
|
including enhancements, upconversions, indexing, analysis/tabulation
|
|
|
|
|
|
Determine the nature of the basic source/result "cast" e.g.
|
|
|
* documentary->documentary
|
|
|
* documentary->structured
|
|
|
* structured->documentary
|
|
|
* mixed (some of each/any/all)
|
|
|
* etc.
|
|
|
|
|
|
Within and sometimes between these categories, it is also not uncommon for more than one purpose or use to be combined in an XSLT.
|
|
|
|
|
|
Plus this phenomenon appears all the way down, i.e. at lower more granular levels
|
|
|
(w/in templates, functions and subordinated stylesheets or processes)
|
|
|
as well as at higher levels
|
|
|
|
|
|
## Assess overall logic
|
|
|
|
|
|
Is there lots of pushing (templates and modes) or pulling (fewer large templates, for-each especially nested `for-each`)
|
|
|
|
|
|
Keep an eye out for features of interest such as
|
|
|
|
|
|
* grouping logic with `for-each-group` or with variable filtering
|
|
|
* handling of cross-referencing structures
|
|
|
|
|
|
## Break the XSLT into component parts conceptually
|
|
|
|
|
|
This can entail actually rewriting it to group its templates differently.
|
|
|
|
|
|
However, this is not always necessary (sometimes it is obvious or they are already well grouped) or possible (sometimes it is not obvious at all and indeed there are several ways one might think about it).
|
|
|
|
|
|
Even if only in one's mental model, the advantage of breaking the XSLT into one or more conceptual families of templates and functions is that it highlights both the general approach being taken, and how algorithms or solutions to problems (micro and macro) are deployed in service to that general approach.
|
|
|
|
|
|
Of course, creators of XSLTs tend to do the same thing over and over, so this is not always a difficult task: often a stylesheet can be cracked like a safe.
|
|
|
|
|
|
## Try it out with some test data
|
|
|
|
|
|
Then mess with it and see if you can get it to behave predictably. |