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 <[EMAIL PROTECTED]> > *To:* Bob Stayton <[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] > > > > > > > > >
