Most (probably all, though I think we'd need more details on the
latter issue) of the behavior you're seeing can be explained by XSLT's
built-in templates. See section 5.8 of the XSLT 1.0 specification
[1], but in short, they are:
<xsl:template match="*|/">
<xsl:apply-templates/>
</xsl:template>
<xsl:template match="*|/" mode="m"><!-- One of these for each mode -->
<xsl:apply-templates mode="m"/>
</xsl:template>
<xsl:template match="text()|@*">
<xsl:value-of select="."/>
</xsl:template>
<xsl:template match="processing-instruction()|comment()"/>
-Brandon :)
[1] http://www.w3.org/TR/1999/REC-xslt-19991116#built-in-rule
On Wed, Apr 20, 2011 at 11:24 AM, Fredrik Bengtsson
<Fredrik(_dot_)Bengtsson(_at_)lemontree(_dot_)se> wrote:
Hi,
I am using FOP trunk to generate PDFs from DocBook documents on the command
line. Fop.bat is doing the XSL transformation, using whatever engine fop uses
(xalan?). I have written the XSLT entirely by myself, i.e. I am not using any
default DocBook transform or similar. The transform is small and under my
strict control.
I am having the problem that the transform does not behave as expected in two
ways:
* Contents of nodes are being copied to the output as if there were some kind
of identity transform in effect by default even though I have not written
one, and
* Matches far down in the document cannot fetch data that existed earlier in
the document, as if select="/x" selected the x post-transform instead of
pre-transform
Imagine a document like this (ignoring namespaces etc for brevity):
<book>
<titleabbrev>THEDOC</titleabbrev>
<chapter>
<title>Ch. 2: The chapter</title>
<titleabbrev>Ch. 2</titleabbrev>
</chapter>
</book>
If I have the following transforms in place:
<xsl:template match="/d:book">
<!-- ignoring root, page-sequence etc for brevity -->
<xsl:apply-templates />
</xsl:template>
<xsl:template match="d:chapter">
<xsl:apply-templates />
</xsl:template>
<xsl:template match="d:chapter/d:title">
<fo:block> ... ... </fo:block>
</xsl:template>
Then for some reason the titleabbrev appears in the output even though I have
not made any rule explicitly matching it. It is caught along with the title
inside the apply-templates under d:chapter. I thought that this would not
happen, unless I really added a matching template of some sort, for example
an identity transform.
I then just for fun tried to add the following template:
<xsl:template match="*" />
That got rid of the offending titleabbrev, BUT it also had the effect of
breaking another template that special-cases the first chapter:
<xsl:template match="d:chapter[1]">
<xsl:variable name="abbr">
<xsl:value-of select="/d:book/d:titleabbrev" />
</xsl:variable>
<!-- note: that selects a node that is higher up in the document -->
<!-- now do something with $abbr -->
</xsl:template>
It seems that at that point, book/titleabbrev has already been transformed,
i.e. removed due to the catch-all template above, so $abbr is empty. That
strikes me as extremely strange; should the select not grab nodes from the
original unmodified document? If I remove the catch-all, $abbr is set
properly just as expected.
This is really confusing! And again - I am not using a huge third-party
transform and modifying it, but rather using a really small, custom-written
and strict one under my control.
/Fredrik
--~------------------------------------------------------------------
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>
--~--
--~------------------------------------------------------------------
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>
--~--