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

Subject: RE: [xsl] Q re Fo internal linking (& xslt processing algorithm)
From: "Khaled Aly" <ka.aly@xxxxxxxxxx>
Date: Wed, 31 Oct 2007 16:45:26 +0200
Thank you very much for the elaboration. It clarifies all about this key
function- you probably agree that fo-pdf cross referencing is important in
comparison to html native support to links and also the fact that it's
rendered without further conversion.

Regarding the processing model algorithm that I mentioned I was seeking, I
feel that it can be of help even from an educational standpoint because some
issues can only be figured by practice and technique. An example of a
document that I found helpful towards this line of thought is the Saxon
anatomy at
http://www.ibm.com/developerworks/library/x-xslt2/?dwzone=x?open&l=132,t=gr,
p=saxon. I realize it is meant to explain the internal processor
implementation, but it also draws on how the source and xslt internal data
structures handling evolves the buildup of the result tree, and that's the
objective from an xslt development perspective. I haven't practiced xslt for
long and I can't tell how practical or feasible it is to produce such. 

I appreciate your help.

|-----Original Message-----
|From: G. Ken Holman [mailto:gkholman@xxxxxxxxxxxxxxxxxxxx] 
|Sent: Tuesday, October 30, 2007 8:03 PM
|To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
|Subject: RE: [xsl] Q re Fo internal linking (& xslt processing 
|algorithm)
|
|At 2007-10-30 19:30 +0200, Khaled Aly wrote:
|>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!
|
|Well, I tell my XSLT students that the processor could very 
|well assign unique identifiers to the nodes at the time it is 
|building the tree, and that the student should think of the 
|concept as "generated id" rather than "generate id" since the 
|same value is always returned for any given node during the 
|execution of the stylesheet.
|
|Either way the end result is the same but I suggest you think 
|of it statically rather than dynamically.
|
|Yes, it is exactly as if the XML element had an actual id.
|
|Note that even if you *do* have an id= attribute, I tell my 
|XSL-FO students that when they are aggregating multiple XML 
|instances into a single XSL-FO result that they should use 
|generate-id() even if the elements have an ID.  What if two 
|XML input source documents are validly using the same ID for 
|different elements?  Each document is correct.  The 
|aggregation in your XSL-FO will introduce ambiguities if you 
|copy the ID attributes into the FO result.  This is not true 
|if you put into the FO result the generate-id() value for the 
|element and not the ID value for the element because the nodes 
|from the two different trees will have different 
|statically-generated identifiers.  This, then, requires you to 
|consider pointing to an authored ID as pointing to the 
|generated identifier by using something along the lines of:
|
|    <page-number-citation ref-id="{generate-id(id(@idref))}"/>
|
|It is important to remember that the persistence of this value 
|is only until the stylesheet finishes executing.  There is no 
|guarantee that the next time you run the stylesheet that you 
|will get the same generated id for each node.  After all, the 
|processor might have used something as low-level as a heap 
|memory address with which to guarantee uniqueness (not that 
|I've seen any implementation do so).
|
|There are zero guidelines on the algorithm to create the id, 
|only the lexical constraint that the resulting id be a valid 
|XML name token comprising only of ASCII alphanumeric 
|characters.  It should be used opaquely ... you should never 
|assume that the identifier is constructed by any particular 
|pattern on the inside.  You can, however, use one given 
|identifier as the basis for making multiple unique identifiers 
|by tacking on the end a ".", "-" or "_" (allowed in XML name 
|tokens) and then using your unique suffixes (if you don't add 
|the non-alphanumeric character then you have an 
|infinitesimally small chance of creating a sequence that the 
|processor might also create).
|
|I hope this helps.  It is a powerful tool to use, and there 
|are many places where it is useful.
|
|. . . . . . . . . . . . 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