Hi Ken,
Thanks for your look, I'll try drilling down where the $node assignment
happens, but I am pretty sure I am not intentionally putting the things
in there that my code exposes.
G. Ken Holman wrote:
Your stylesheet doesn't compile standalone because of missing template
rules, which indicates to me there are other fragments at play.
That is correct, since it is part of a whole, which includes about 15
XSL files. I'll try to isolate the issue in a smaller single-file XSL
sheet for this list.
Furthermore, the failing template receives two nodes in a variable
that I hardly expect to be grouped together. In the source document
they are not even siblings.
Expose your $node variable after you assign it and see where it gets
more than one node in it.
The $node variable is not used at all in the way I am using the
templates at the moment. What I try to do is use some slightly complex
way of splitting
a TEI into manageable sized chunks while converting it to XHTML for ePub
consumption, and a range of related ePub support files. I need to do the
same complex splitting in four different
cases, so instead of writing the complex splitting code several times, I
wrote it once, giving an additional parameter $action through the entire
recursion, to select what
to do when I've reached the bottom of the recursion. In some cases, I
need an additional $node parameter, but in the case that puzzles me, no
$node parameter
is needed. I now explicitly set it to the empty string at calling time,
but the issues still appears.
The current question is, how can a trace show an error in a stylesheet
that is not even matched or called in the stylesheet higher on in the trace.
Jeroen.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--