Wow, now come to think of it I DID stop to think at one time why I did not have
to write a specific rule for text(). This explains it. Well that behavior is
fine, I'll keep that. But getting the values of @* and recursing into *|/ are a
downright disaster in my case!
What I need to express is that whenever a node is examined that does not have
an explicit matching template (well, except the one template that achieves just
that, of course), then that node is discarded entirely and is NOT descended
into, i.e. its children are ignored too. So ... if I understand this correctly,
I should be able to get what I want just by adding
<xsl:template match="*|@*" />
I'll try that at work tomorrow.
As an aside - wow, that combination of rules you listed below sure do give
strange results sometimes. <book> has an entire <info> hierarchy below it, and
all of its textual content is copied into the output in one big mess, but with
all of the actual elements stripped out. That's just ... Well, now it makes
sense anyway, thanks for informing me.
/F
-----Original Message-----
From: Brandon Ibach [mailto:brandon(_dot_)ibach(_at_)single-sourcing(_dot_)com]
Sent: den 20 april 2011 17:59
To: xsl-list
Subject: Re: [xsl] Copy-per-default
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>
--~--
--~------------------------------------------------------------------
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>
--~--