You put your finger exactly on the difference in the last paragraph. XSLT is not a sequential processing language. It proceeds through the templates rather than the document, processing those parts of the document that relate to each template, and then putting the whole thing together at the end. It is the templates that are "processed" not the document. Different strategies are employed by different XSLT processors for holding the results of each template's work until that last step wherein the result tree is output.
It is a very different model from that employed in some other processing languages as you point out and the topic of lively debate among programmers on the XSLT list who are familiar with one approach or the other and who have personal, almost theological perspectives on the merits and defects of different programming languages.
As to the table of contents, there are multiple templates in the stylesheet that Linda uses that transform <head> elements as they appear in the body of the finding aid and one that populates the table of contents. In the latter case, look for a template whose name is "toc".
Michael
-----Original Message-----
From: Encoded Archival Description List [mailto:[log in to unmask]]On Behalf Of
MicheleR
Sent: Wednesday, April 13, 2005 10:23 AM
To: [log in to unmask]
Subject: I/O flow with XSLT
I've been looking in depth at Linda's example with the two style sheets
which creates the TOC down the left-hand side, and I have a more general
question on the flow of the processing.
Since the toc is created in the left-hand column, and needs information from
the entire xml document; and since the body of the document is created in
the right-hand column and also needs information from the entire xml
document; am I right in thinking that the xml document is actually processed
twice, once to create the toc and then again to create the body of the page?
As I work through the style sheets, that's how it looks -- I don't see
anything in the XSL code that allows you to store information and reference
it later. But it must be there, otherwise how would you create links to
things (you need the information once for the link and then again for the
target, to create a matching id, right?).
As opposed to processing the document once; storing each toc element in
memory as it's encountered; storing the body information in memory as its
encountered; and then at the end spitting out all the toc information into
the first <td></td> followed by all the body information in the next
<td></td>.
Hope this question makes sense. We used to process structured documents
using a language called Omnimark, which processed the document sequentially
once, matching each element using the equivalent of templates, but it didn't
output anything until the complete document had been passed through the
code; this allowed you to store various bits of information in different
buffers and arrays, insert placeholders that were resolved at the end of
processing, and generally manipulate the entire document structure as
desired, prior to actually outputting anything. I'm used to thinking in
this manner and don't quite grasp the flow for XSLT yet.
Thanks
Michele
|