Thank you for the helpful response.
If I'm making the right conclusion, it means that the first use of
generate-id() without an argument in the context of a given xml element
associates the generated value to that element till processing ends - and
that every subsequent invocation when the same xml element is current will
return the same value? That's in spite of that fact that the function is
invoked from within a lateral fo element.
It worked for me this way, just as if the xml element had an actual id, but
I don't know if the generalization is correct!
Best regards.
-----Original Message-----
From: G. Ken Holman [mailto:gkholman(_at_)CraneSoftwrights(_dot_)com]
Sent: Monday, October 29, 2007 11:10 PM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] Q re Fo internal linking (& xslt processing algorithm)
At 2007-10-29 22:45 +0200, Khaled Aly wrote:
I've got this little problem of producing Fo ToC entries' hyper-links
to their respective pages (or page positions). The DTD has no ID type
attributes that could be used in the xslt based on their xml document
element associations.
You can create your own ID value for any node by using the
generate-id() function. But reading on I see that you've already figured
that out.
I create the ToC within the root template (directly in the xslt file
using a "front pages" Fo page sequence, since there is no ToC xml
element. It is positioned before the apply-templates instruction that walks
down the tree.
It was no problem to generate page numbers using
<fo:page-number-citation ref-id="{generate-id()}"/> within the ToC
table cell that should contain the page #, paired with an
id="{generate-id()} attribute within the page title block, defined in a
downstream page title template. I don't understand precisely how these
two randomly generated id's
They aren't random. By omitting an argument to generate-id() it is acting
on the current node, and in both cases your current node is the same, so you
are getting the same result.
are paired to match for a
number of page/section title elements, while they were created
independently, but it works!
Because you so very strategically (I'm sure!) ensured the same current node
each time, it worked as needed.
What I can't get to work is the use of fo:basic-link with an
internal-destination attribute so that the page corresponding to a
title can be reached by clicking its ToC title. I assigned the
following value to the internal-destination attribute: <xsl:value-of
select="child::node()/@id"/> (the subject fo:block is the only child).
But the *.fo file comes with an empty id. That's what I get in proper
fo positions: <fo:basic-link internal-destination=""/>.
But XSLT instructions act on the source tree, not the result tree. You say
"the subject fo:block is the only child", but that cannot be true because
the XSL-FO is in your result tree ... the child axis is relative to the
current node in the source tree.
Is it that the @id is not known/generated at this early point of
processing where the template being applied is the root, or is there
something v. basic wrong with my xpath expression?
I think you are just not thinking from the right perspective. You state you
are at the root, but that isn't true if you are in the middle of processing
a TOC entry for a descendent section construct.
I hope I managed to describe this clearly as I couldn't find it v.
practical to cite just the relevant code. It seems to me that this
should be a typical issue with a standard solution. Just the
implementations may be different.
It is quite typical: do all the work in the TOC with your current node
being the node that will subsequently be processed in the body, then when
processing the body do the corresponding work with the same node as being
current. Or, if not current in either case, addressable.
Many thanks.
ka
Side note: Are there available resources that describe in an accurate
informal-algorithmic way the procedure followed by xslt processors
(generically or for a particular processor) in evolving the internal
data structures representing both template rules and both input and
result nodes;
The specification is written such that stylesheet writers don't need to know
the internals. They are irrelevant to a portably-written stylesheet.
towards resolving all template rules and generating the complete output
tree? Some things are intuitively clear but some cases, may be like my
above issue, cannot be guessed (at least as it seems to me!).
The specification describes the functionality of all functions, including
generate-id() ... I think it is just a matter of getting familiar with their
use.
You shouldn't have to know the internals at all. I don't even think about
the internals, except perhaps keeping in mind stylesheet-writing
optimizations that would enable tail-recursion to be used by the processor.
I could find general
descriptions to different xslt processing aspects, but failed to find a
complete algorithm-like description that leaves little room for
ambiguities.
The spec has little room for ambiguities, as all the conforming processors
are evidence. The internals are purposefully not specified so that
innovation can prevail by processor writers.
I hope this is helpful ... if you think you need to know the internals, then
you probably just need practice to be more familiar with the behaviour of
all of the function library.
. . . . . . . . . . . Ken
--
Comprehensive in-depth XSLT2/XSL-FO1.1 classes: Austin TX,Jan-2008
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 Jul'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>
--~--
--~------------------------------------------------------------------
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>
--~--