Re: [xsl] Q re Fo internal linking (& xslt processing algorithm)

Subject: Re: [xsl] Q re Fo internal linking (& xslt processing algorithm)
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 29 Oct 2007 17:10:03 -0400
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@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 Jul'07  http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

Current Thread