OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC