Regarding option #1 using olinks for cross references within a glossary
collection, I don't think this will work with the current setup. The
problem is that the templates that collect the olink target data do not
process an automatic glossary before extracting the target information. It
probably should, but currently does not. So that means the olink database
won't have the target information for the generated glossentries. You could
file that as a bug report on the SourceForge DocBook site so it gets fixed.
I think approach #3 is probably easiest. Below is an example XSL code to
the template for glossseealso to add an xsl:when clause when an xlink is
available. It also handles the "See Also" part. It uses mode="xref-to" to
generate the link text for the target entry if the glossseealso element is
empty.
<xsl:template match="d:glossseealso" mode="glossary.as.list">
<xsl:variable name="otherterm" select="@otherterm"/>
<xsl:variable name="targets" select="key('id', $otherterm)"/>
<xsl:variable name="target" select="$targets[1]"/>
<xsl:variable name="xhref" select="@xlink:href"/>
<xsl:choose>
<xsl:when test="$target">
<fo:basic-link internal-destination="{$otherterm}"
xsl:use-attribute-sets="xref.properties">
<xsl:apply-templates select="$target" mode="xref-to"/>
</fo:basic-link>
</xsl:when>
<xsl:when test="$xhref">
<xsl:variable name="idref">
<xsl:call-template name="xpointer.idref">
<xsl:with-param name="xpointer" select="$xhref"/>
</xsl:call-template>
</xsl:variable>
<xsl:variable name="xtargets" select="key('id',$idref)"/>
<xsl:variable name="xtarget" select="$xtargets[1]"/>
<xsl:call-template name="check.id.unique">
<xsl:with-param name="linkend" select="$idref"/>
</xsl:call-template>
<xsl:choose>
<xsl:when test="count($xtarget) = 0">
<xsl:message>
<xsl:text>XLink to nonexistent id: </xsl:text>
<xsl:value-of select="$idref"/>
</xsl:message>
</xsl:when>
<xsl:otherwise>
<fo:basic-link internal-destination="{$idref}">
<xsl:choose>
<xsl:when test="string-length(.) != 0">
<xsl:apply-templates/>
</xsl:when>
<xsl:otherwise>
<xsl:apply-templates select="$xtarget" mode="xref-to"/>
</xsl:otherwise>
</xsl:choose>
</fo:basic-link>
</xsl:otherwise>
</xsl:choose>
</xsl:when>
<xsl:when test="$otherterm != '' and not($target)">
<xsl:message>
<xsl:text>Warning: glossseealso @otherterm reference not found:
</xsl:text>
<xsl:value-of select="$otherterm"/>
</xsl:message>
<xsl:apply-templates mode="glossary.as.list"/>
</xsl:when>
<xsl:otherwise>
<xsl:apply-templates mode="glossary.as.list"/>
</xsl:otherwise>
</xsl:choose>
<xsl:choose>
<xsl:when test="position() = last()">
<xsl:text>.</xsl:text>
</xsl:when>
<xsl:otherwise>
<xsl:text>, </xsl:text>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
Bob Stayton
Sagehill Enterprises
[email protected]
----- Original Message -----
From: "Bergfrid Skaara" <[email protected]>
To: <[email protected]>
Sent: Friday, March 20, 2009 10:07 AM
Subject: [docbook-apps] how to do modular glossaries with 5.0 ?
Hi, I'm building multiple glossaries from a modular master glossary
and find the validation errors triggered by the otherterm constraint
on glosssee and glossseealso distracting.
The modularization is done as follows: 1 file for each letter a-z
containing individual glossentries on that letter + 1 master book file
for each glossary, xincluding by xml:id from those files.
What I would like most of all is to use the same setup as for master
bibliography, referencing a single bib. file using bibliomixed, but I
don't get this to work since the glossentries are split on 26 files.
My immediate challenge is however validation of the individual files,
since the otherterm constraint on glosssee and glossseealso uses id
and not xml:id and only see elements within the same document (file).
I can live with this, but our non-technical wysiwyg users cannot.
I'm considering the following options - any pro/con, implementation
suggestions, and alternative solutions are welcome.
1) redefine glosssee and glossseealso to behave like olinks by
replacing otherterm attribute with targetdoc and targetptr and writing
some templates to handle it (which we are already using)
2) suppress the otherterm validation errors by customization (removing
schematron rules) - guess I'd have to QA the see links manually then
3) link by using xlink:href rather than otherterm and write a custom
template to add and format the generated text (See / See also)
Best regards, Bergfrid Skaara
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
