This is the mail archive of the
docbook-apps@lists.oasis-open.org
mailing list .
RE: Getting revhistory/revision[1]/revnumber on atitlepage
- From: David Cramer <dcramer at broadjump dot com>
- To: docbook-apps at lists dot oasis-open dot org
- Date: Thu, 23 Jan 2003 12:01:51 -0600
- Subject: DOCBOOK-APPS: RE: Getting revhistory/revision[1]/revnumber on atitlepage
> You can do this:
>
> <t:titlepage-content side="verso">
> <releaseinfo fo:font-size="8pt"/>
> <!-- Trying to get it to put only the revnumber for
> the first revision in document order -->
> <revhistory/>
> ...
>
> And then add a template:
>
> <xsl:template match="revhistory" mode="?book?.titlepage.verso.mode">
> <!-- do whatever you want here, such as: -->
> <xsl:apply-templates select="revision[1]/revnumber"/>
> </xsl:template>
Ah. That makes sense--in fact I'm certain that I've read that somewhere before in a post or in Bob's book.
> |> When I generate an xsl from this, it seems like it's
> |> starting to do what I want, but not quite. There's no
> |> template matching revision or revnumber in
> |> book.title.page.verso.auto.mode. I would expect it to
> |> create a template matching revision that in turn applies
> |> templates to revnumber (and one matching revnumber that
> |> puts the contents of revnumber in a fo:block with
> |> font-size="8pt" in the output. The result is the same using
> |> 1.59.2 and older titlepage.xsls.
>
> It could work that way, but asking the template stuff to process ever
> deeper levels would make it that much more complex.
Yes, I can see where it's not worth the trouble given the ease of doing what you suggest above.
<snip/>
> Now that I look a little more closely, I see what t:or was for:
>
> <para>Usually, the elements so named are empty. But it is
> possible to
> make one level of selection within them. Suppose that you want to
> process <literal>authorgroup</literal> elements on the
> title page, but
> you want to select only proper authors, editors, or
> corporate authors,
> not collaborators or other credited authors.</para>
>
> <para>In that case, you can put a <literal>t:or</literal>
> group inside
> the <literal>authorgroup</literal> element:
>
> <screen><![CDATA[
> <t:titlepage-contents side="recto">
> <!-- other titlepage elements -->
> <authorgroup>
> <t:or>
> <author/>
> <editor/>
> <corpauthor/>
> </t:or>
> </authorgroup>
> <!-- other titlepage elements -->
> </t:titlepage-contents>
> ]]></screen>
> </para>
>
> But in the absence of t:or, it might or might not make sense to
> process all the children because what you really might want to do is
> process the element.
I have to admit, I don't understand that last sentence. However, I think I see what's happening by doing an experiement. I did the authorgroup example above both with and without a t:or:
With t:or (this would process all authorgroup/authors, authorgroup/editors, and autorgroup/corpauthors in the order that they appear in the authorgroup in the source document, correct?):
<xsl:template match="authorgroup" mode="article.titlepage.recto.auto.mode">
<xsl:apply-templates select="author|editor|corpauthor" mode="article.titlepage.recto.auto.mode"/>
</xsl:template>
Without t:or (this would process all the authorgroup/authors, then the authorgroup/editors, then the authorgroup/corpauthors, correct?):
<xsl:template match="authorgroup" mode="article.titlepage.recto.auto.mode"><xsl:apply-templates select="author" mode="article.titlepage.recto.auto.mode"/><xsl:apply-templates select="editor" mode="article.titlepage.recto.auto.mode"/><xsl:apply-templates select="corpauthor" mode="article.titlepage.recto.auto.mode"/>
</xsl:template>
Here's something curious. When I try the authorgroup example, it works as described. However, when I try this:
<t:titlepage-content side="verso">
<releaseinfo fo:font-size="8pt"/>
<revhistory>
<t:or>
<revision/>
</t:or>
</revhistory>
... I end up with two templates matching revhistory in the same mode in the output:
<xsl:template match="revhistory" mode="book.titlepage.verso.auto.mode"><xsl:apply-templates select="revision" mode="book.titlepage.verso.auto.mode"/>
</xsl:template>
<xsl:template match="revhistory" mode="book.titlepage.verso.auto.mode">
<fo:block xmlns:fo="http://www.w3.org/1999/XSL/Format" xsl:use-attribute-sets="book.titlepage.verso.style">
<xsl:apply-templates select="." mode="book.titlepage.verso.mode"/>
This is academic given that the technique you describe above will do everything I need, but I'm confused as to why there's a problem with revhistory and not authorgroup. I can make the extra revhistory go away by adding 'and not(./*)' to a a test in the for each in the template that matches t:titlepage:
<xsl:for-each select="t:titlepage-content/*">
<xsl:variable name="thisnode" select="."/>
<xsl:if test="(not(@suppress-template) or @suppress-template='0')
and (not(@force) or @force='0')
and (not(preceding-sibling::*[name(.)=name($thisnode)]))
and not(./*)"><!-- Don't create a template if the element has children because there's a template in mode="special.rules" that will take care of it. -->
Thanks,
David