So does this mean I need to know the structure of the XML at block level?
I am hoping for a dynamic XSL:FO version that will allow the XML to "published"
with node names and values. It does not need to be in a pretty format, a simple
single string would be adequate although not appealing.
Re: So you need something explicitly recognizing your block-level constructs
along the lines of:
<fo:flow ...>
<xsl:apply-templates/>
</fo:flow>
<xsl:template match=" thisblock | thatblock | otherblock ">
<fo:block>
<xsl:apply-templates/>
</fo:block>
</xsl:template>
Thanks again in advance for the help that you have all given.
Chris
-----Original Message-----
From: G. Ken Holman [mailto:gkholman(_at_)CraneSoftwrights(_dot_)com]
Sent: 16 September 2011 18:31
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: RE: [xsl] XSL:FO Identify Transforms
At 2011-09-16 18:17 +0100, Chris Booth wrote:
Based on this template:
<xsl:template match="node() | @*">
<xsl:copy>
<xsl:apply-templates select="@* | node()" />
</xsl:copy>
</xsl:template>
I was trying to construct in FO, but not quite there. I feel I am
missing your suggestion
That I think you cannot have a generic solution matching nodes regardless of
their name.
Some of your XML constructs are block-level and some are inline-level.
So you need something explicitly recognizing your block-level constructs along
the lines of:
<fo:flow ...>
<xsl:apply-templates/>
</fo:flow>
<xsl:template match=" thisblock | thatblock | otherblock ">
<fo:block>
<xsl:apply-templates/>
</fo:block>
</xsl:template>
You don't need a template rule for inline constructs, but you may want to
introduce one if you want to decorate your inline content:
<xsl:template match=" thisinline ">
<fo:inline ....>
<xsl:apply-templates/>
</fo:inline>
</xsl:template>
<xsl:template match=" thatinline ">
<fo:inline ....>
<xsl:apply-templates/>
</fo:inline>
</xsl:template>
I'm not sure of the utility of your one-cell, one-row table direction you were
headed. And your nested <xsl:for-each> won't achieve what you are looking for
because that pull approach of two constructs only goes two levels deep in your
structure.
The above push approach will address all the levels of your input XML.
I hope this helps.
. . . . . . . . . Ken
--
Contact us for world-wide XML consulting and instructor-led training
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
G. Ken Holman mailto:gkholman(_at_)CraneSoftwrights(_dot_)com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
--~------------------------------------------------------------------
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>
--~--
________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The service is powered by
MessageLabs. For more information on a proactive anti-virus service working
around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________
________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________
--~------------------------------------------------------------------
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>
--~--