Subject: RE: [xsl] Q re Fo internal linking (& xslt processing algorithm) From: "Khaled Aly" <ka.aly@xxxxxxxxxx> Date: Tue, 30 Oct 2007 19:30:16 +0200 |
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@xxxxxxxxxxxxxxxxxxxx] Sent: Monday, October 29, 2007 11:10 PM To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx 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@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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Q re Fo internal linking , G. Ken Holman | Thread | Re: [xsl] Q re Fo internal linking , David Carlisle |
Re: [xsl] Adding a border to graphi, G. Ken Holman | Date | Re: [xsl] Q re Fo internal linking , David Carlisle |
Month |