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) > 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(_at_)CraneSoftwrights(_dot_)com
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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--