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.
 
 


________________________________

        From: Bob Stayton [mailto:[EMAIL PROTECTED] 
        Sent: Friday, April 04, 2008 9:10 AM
        To: Mimil Mimil
        Cc: [email protected]
        Subject: Re: [docbook-apps] Duplicate IDs mess up FO TOC
        
        
        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?
         
        Bob Stayton
        Sagehill Enterprises
        [EMAIL PROTECTED]
         
         

                ----- Original Message ----- 
                From: Mimil Mimil <mailto:[EMAIL PROTECTED]>  
                To: Bob Stayton <mailto:[EMAIL PROTECTED]>  
                Cc: [email protected] 
                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
<[EMAIL PROTECTED]> 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?  
                         
                        
                        Bob Stayton
                        Sagehill Enterprises
                        [EMAIL PROTECTED]
                         
                         

                                ----- Original Message ----- 
                                From: Mimil Mimil
<mailto:[EMAIL PROTECTED]>  
                                To: Bob Stayton
<mailto:[EMAIL PROTECTED]>  
                                Cc: [email protected] 
                                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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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::[EMAIL 
PROTECTED] =
$id])"/>
                                
                                 <xsl:variable name="preceding.xid"
                                      select="count(preceding::[EMAIL 
PROTECTED]: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
                                [EMAIL PROTECTED]
                                
                                
                                ----- Original Message ----- From:
"Claus Rasmussen" <[EMAIL PROTECTED]>
                                To: <[email protected]>
                                Sent: Wednesday, January 17, 2007 7:02
AM
                                Subject: [docbook-apps] Duplicate IDs
mess up FO TOC 




                                Hi folks,
                                
                                I'm reusing quite a few sections using
xincludes and my table of contents
                                gets confused when generating PDF
output: It can not correctly determine the
                                page number of all sections since
multiple sections have the same ID (the
                                ones that are reused).
                                
                                I'm fully aware that duplicate ID
attributes in my aggregated document makes
                                it invalid, but ignoring that for a
while, would any of you know how to
                                solve this problem and get a nice
printed TOC?
                                
                                Of course there's the laborous approach
suggested by Bob
        
(http://www.sagehill.net/docbookxsl/DuplicateIDs.html) but that's not
really
                                feasible in this case.
                                
                                Best,
                                Claus
                                
                                -- 
                                http://techwriter.dk/
                                
                                
        
---------------------------------------------------------------------
                                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]
                                
                                




Reply via email to