Hi Robert,



...



   <xsl:when test="value and not($col)">
       <fo:table-row>
           <fo:table-cell><xsl:value-of select="title"/></fo:table-cell>
           <fo:table-cell>text</fo:table-cell>
           <xsl:variable name="col" select="'true'"/>
   </xsl:when>
   <xsl:when test="value and $col">
           <fo:table-cell><xsl:value-of select="title"/></fo:table-cell>
           <fo:table-cell>text</fo:table-cell>
        </fo:table-row>
        <xsl:variable name="col" select="''"/>
   </xsl:when>

...



This obviously will not work, because XSLT does not allow variables to
be reassigned.

Worse: this violates the well-formned requirement of XML.



> After reading extensively from O'Reilly's XSLT book
and the w3c specs for XSLT and XPath, I decided I could achive my goal
with recursive template matches.  Here is what I arrived at:

/----------------------------------------------------------------------------------------<xsl:stylesheet . . .>
   <xsl:template match="document">
. . .
        <fo:table-body>
            <xsl:apply-templates select="field[1]">
        </fo:table-body>
. . .
   </xsl:template> <!-- end template match="document" -->
   <xsl:template match="field">
       <xsl:choose>
           <!-- When current <field> has <value/> and next <field>
has <value/> -->
           <xsl:when test="value and following-sibling::field[1]/value">
               <fo:table-row>
                   <fo:table-cell>
                       <!-- current title -->
                       <fo:block><xsl:value-of select="title"/></fo:block>
                   </fo:table-cell>
                   <fo:table-cell>
                       <fo:block>text</fo:block>
                   </fo:table-cell>
                   <fo:table-cell>
                       <!-- next title -->
                       <fo:block><xsl:value-of
select="following-sibling::field[1]/title"/></fo:block>
                   </fo:table-cell>
                   <fo:table-cell>
                       <fo:block>text</fo:block>
                   </fo:table-cell>
               </fo:table-row>
               <!-- use this template for the next element (after the
one previously referred
                     to as 'next'. omitting the final '[1]' will
cause this template to be processed
                     remaining <field>, which results in very long
files with lots of stuff i don't
                     want. -->
               <xsl:apply-templates
select="following-sibling::field[position() &gt; 1][1]"/>

Err, why not use "following-sibling::field[2]"? :-)



           </xsl:when>
           <!-- if not. . . -->
           <xsl:otherwise>
               <fo:table-row>
                   <fo:table-cell>
                       <fo:block><xsl:value-of select="title"/></fo:block>
                   </fo:table-cell>
                   <fo:table-cell number-columns-spanned="3">
                       <fo:block>other text</fo:block>
                   </fo:table-cell>
               </fo:table-row>
               <!-- use this template for the next element. again,
don't omit '[1]'. -->
               <xsl:apply-templates select="following-sibling::field[1]"/>
           </xsl:otherwise>
       </xsl:choose>
   </xsl:template>
\------------------------------------------------------------------------------------/

This works great.  Based on my understanding of the XSLT parsers, this
is pretty memory intensive, as applying "following-sibling::field[1]"
actually passes the remaining <field> nodes in <document> every time,
leaving a lot of stuff in the stack. Is that correct?

I'm not sure what you mean by this, but "following-sibling::field[1]" results in a node-set with 
either one or zero elements named field. So for at most one element a new apply-templates is being 
issued.



It is true that when you have n field siblings, you potentially build up a stack of n 
apply-templates calls, but it isn't so that all field siblings are stacked each time. There is no 
need for this. The field nodes are in the source tree and are always available. The things that do 
need to be cached are the pointer to the current node, the current context list (here in most cases 
a node-set of only one field node) and variables if you would be using them...



At any rate, any ideas on a better way to do this?  (Other than a SAX
parsing of the XML with a few variables and leaving an extra node in
select <field>s.)

No, I think it is perfectly sound already... except for the [position() > 1][1], you can simply 
replace that by [2]...



G.