RE: [docbook-apps] Duplicate IDs mess up FO TOC

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:] 
  
Sent: Friday, April 04, 2008 9:10 AM
To: Mimil 
  Mimil
Cc: 
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


  
 

  
 

  
    
----- Original Message ----- 

    
From: 
    Mimil 
    Mimil 

    
To: Bob Stayton 

    
Cc:  
    

    
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 <> 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


      
 

      
 

      
        

        
----- 
        Original Message ----- 

        
From: 
        Mimil Mimil 

        
To: 
        Bob Stayton 

        

        

        

        
Cc: 
         

        
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 
        <> 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 
          <> 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


----- Original 
            Message ----- From: "Claus Rasmussen" <>
To: <>
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: 
For 
              additional commands, e-mail: 

---------------------------------------------------------------------
To 
            unsubscribe, e-mail: 
For 
            additional commands, e-mail: