RE: [xsl] Check for duplicate @id's - collection()

Subject: RE: [xsl] Check for duplicate @id's - collection()
From: "Philip Vallone" <philip.vallone@xxxxxxxxxxx>
Date: Sat, 19 Jul 2008 14:56:00 -0400
Hi Ken,

>What you lose is the ability to link from outside *in* to your aggregated
file, in which case your uniqueness guarantee is obliged to be pushed back
to 
the authoring side.

Most of my xsl uses generate-id() for my blocks or anchors.  It's when the
author has to manual create a link for the purpose of hyperlinking or for
content re-use. The template leaves the option open to the author (a scary
concept). If there is no @id, then one is created.

>... and then the processor you use coincidentally returns that very same
string as a generated identifier for a different node.  It is a remote
chance, but you cannot guarantee there won't be a value collision.

This is why I am trying to build all the error traps. The odds of
generate-id() returning the same string is very very slim. In this case, all
800 files follow a single schema. During authoring, the tech writer will
copy and paste whole fragments, not realizing they have coping over @ids.
The author induces the problem. So the majority of my time is to Murphy
proof my xslts.

>What you lose is the ability to link from outside *in* to your aggregated
file

In this case, do you mean link *into* the pdf from an outside document?

Thank you,



-----Original Message-----
From: G. Ken Holman [mailto:gkholman@xxxxxxxxxxxxxxxxxxxx] 
Sent: Saturday, July 19, 2008 12:24 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: [xsl] Check for duplicate @id's - collection()

At 2008-07-19 12:09 -0400, Philip Vallone wrote:
>This is a great idea which I currently use the following template for:
>
><xsl:template name="get-mandatory-id">
>                 <xsl:param name="id-val"/>
>                 <xsl:choose>
>                         <xsl:when test="string-length($id-val) &gt; 0">
>                                 <xsl:value-of select="$id-val"/>
>                         </xsl:when>
>                         <xsl:otherwise>
>                                 <xsl:value-of select="generate-id()"/>
>                         </xsl:otherwise>
>                 </xsl:choose>
>         </xsl:template>

The problem with the above, and why I never use it, is the very small (but
not zero) chance that your document author creates XML along the lines of
the following thinking it is not going to be used by other authors:

       id="d0e7"

... and then the processor you use coincidentally returns that very same
string as a generated identifier for a different node.  It is a remote
chance, but you cannot guarantee there won't be a value collision.

I tell my students that if they use generate-id() for a value set they
should *only* use generate-id() for all values in the set.

>However, I also use some of the IDs for cross-referencing for PDF 
>output and HTML. So generating the id dynamicly is something I can't 
>always do, unless I am missing the obvious?

Perhaps you are missing something ... XSLT was originally designed for use
with XSL-FO ... the specification for generate-id() requires the return
value to be a valid XML name, suitable for cross-referencing *within* PDF
files and HTML files.  Yours is the use case for which generate-id() was
created:  ensuring uniqueness amongst multiple aggregated source trees for
the purposes of cross-referencing using XML/HTML-suitable identifier values.

What you lose is the ability to link from outside *in* to your aggregated
file, in which case your uniqueness guarantee is obliged to be pushed back
to the authoring side.  If you are linking from outside in and two authors
have used the same value, you have no idea which one is the intended one.
And then there is a whole maintenance question of tracking who is using
which identifiers and what they mean.  In which case Michael's code can be
used as a check.

I hope this helps.

. . . . . . . . . . . . Ken

--
Upcoming XSLT/XSL-FO hands-on courses:      Wellington, NZ 2009-01
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

Current Thread