|
I think that you would need to require an additional
attribute on the link itself in order to uniquely identify the intended
destination. Going off Bob's idea of looking at ancestors, this additional info.
could point to an ancestor of the target element that itself has a unique
ID, and contains no other instances of the target itself. For
example:
<link linkend="target_id"
type="target_ancestor_id">test of link</link>
It would be up to the author to ensure that such an
ancestor exists and itself has a unique ID, but I don't think that is an
unreasonable constraint.
I understand the problem, but I don't have a
better solution for your situation. A link references a single id, and
I'm not clear how a template to resolve a linkend could determine which of
several duplicate ids it should reference. I suppose you could compare
ancestors until you find a common one, but that might not guarantee a unique
choice. Anyone else have ideas?
----- Original Message -----
Sent: Friday, April 04, 2008 4:35
AM
Subject: Re: [docbook-apps] Duplicate
IDs mess up FO TOC
Hello,
Indeed I was not talking about a particular
case of inclusion, just talking about the *problem* of your template when
using XInclude.
Your template considers the first id occurrence as
the original one (I mean conserving the id as is) and appends to all others
a number. So if you make links to this id it will point to the first
occurrence found and this may be not what you want.
Imagine you have an
appendix and you include some parts of it within your chapters content (it
avoids writing the same things multiple times) and if in another part you
make link to the appendix content you will be redirected to the first part
within the chapter content instead of the appendix part.
This is
maybe an unusual case but if it is possible to take care of it, it will not
be anymore a problem.
Regards,
Cedric,
On Wed, Apr 2, 2008 at 5:34 PM, Bob Stayton < bobs@sagehill.net> wrote:
Well, if you mean using xml:base to detect
XIncluded content, that could certainly work. It wouldn't work for
the duplicate ids coming from a bibliography collection, which was the
topic of this thread, because XInclude is not used there. The
stylesheet directly opens the database file and processes elements from
it.
I'm not sure if there would always be an
"original" one, though. A chapter could have all of its content
XIncluded, no?
-----
Original Message -----
Sent:
Wednesday, April 02, 2008 6:02 AM
Subject:
Re: [docbook-apps] Duplicate IDs mess up FO TOC
While being on this topic,
Bob don't you
think that checking the xmlbase attribute (maybe there is a clever
algorithm hidden) to discover if the id is the original one or an
included one. Your snippet takes the first one as the original one which
is not always the case.
Do you see what I mean?
Do you think
it is achievable using the xmlbase
attribute?
Regards,
Mimil
On Wed, Apr 2, 2008 at 2:49 PM, Mimil Mimil
< mimilowns@gmail.com> wrote:
Hello
Bob,
I think I discovered a little bug in the XML snippet you
made. On the test dealing with @xml:id you made a concat with @id
instead of @xml:id
<xsl:when test="$object/@xml:id and
$preceding.xid != 0">
<xsl:value-of
select="concat($object/@xml:id, $preceding.xid)"/>
</xsl:when>
Regards,
Mimil
On Wed, Jan 17, 2007 at 7:17 PM, Bob Stayton
< bobs@sagehill.net> wrote:
Here
is a solution that will appear in the forthcoming Fourth Edition of
my book (no release date yet).
The object.id template is used to generate the output
id attribute as well as the link for any element. As long as
it produces consistent output for the same element, your links
should work.
In this customization, it counts the number of
preceding elements with the same id. If the count is greater
than zero, then it appends the count to the id value. It works
with both @id and @xml:id for db5 documents.
<xsl:template
name="object.id">
<xsl:param
name="object" select="."/>
<xsl:variable
name="id" select="@id"/>
<xsl:variable name="xid"
select="@xml:id"/>
<xsl:variable name="preceding.id"
select="count(preceding::*[@id =
$id])"/>
<xsl:variable
name="preceding.xid"
select="count(preceding::*[@xml:id =
$xid])"/>
<xsl:choose>
<xsl:when
test="$object/@id and $preceding.id != 0">
<xsl:value-of select="concat($object/@id, $preceding.id)"/>
</xsl:when>
<xsl:when
test="$object/@id">
<xsl:value-of
select="$object/@id"/>
</xsl:when>
<xsl:when test="$object/@xml:id and $preceding.xid !=
0">
<xsl:value-of select="concat($object/@id,
$preceding.xid)"/>
</xsl:when>
<xsl:when test="$object/@xml:id">
<xsl:value-of select="$object/@xml:id"/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="generate-id($object)"/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
Bob
Stayton
Sagehill Enterprises
DocBook Consulting
bobs@sagehill.net
----- Original
Message ----- From: "Claus Rasmussen" <claus@webclaus.com>
To: <docbook-apps@lists.oasis-open.org>
Sent:
Wednesday, January 17, 2007 7:02 AM
Subject: [docbook-apps]
Duplicate IDs mess up FO TOC
|