RE: [xsl] Getting all the values between empty elements

Subject: RE: [xsl] Getting all the values between empty elements
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Mon, 05 Jan 2004 18:20:58 -0500
Kyle,

You can associate text nodes with their next-immediately-following tab or br, whichever comes first, with a key, as follows:

<xsl:key name="text-by-delim" match="text()" use="generate-id((following::tab|following::br)[1])"/>

This may seem bizarre (it is), but it's useful; you can now retrieve all the text nodes that "belong" to a tab or a br by using the key function. This also has the nice property of retrieving an empty node set for those tabs or brs that "own" no text nodes, so you can simplify your conditional logic:

<xsl:for-each select="preceding-sibling::ws:tab">
  <xsl:variable name="tab-number" select="position()"/>
  <xsl:if test="$tab-number&gt;$lower-limit and $tab-number&lt;=$upper-limit">
    <fo:table-cell>
      <fo:block>
        <xsl:apply-templates select="key('text-by-delim',generate-id())"/>
        <xsl:if test="not(key('text-by-delim',generate-id()))">
          <xsl:text>&#160;</fo:text>
        </xsl:if>
      </fo:block>
    </fo:table-cell>
  </xsl:if>
</xsl:for-each>
<xsl:apply-templates select="key('text-by-delim',generate-id())"/>

Since this key is defined to use the generated id of the first subsequent tab or br to grab a text node, to get them all you'll have to make sure they key function is called with both tabs and brs as context (that's what the final apply-templates is for, to do it for the br).

You might also be able to use this approach (though a different key) to associate tabs with brs, thereby avoiding having to do the ingenious lower-limit/upper-limit hackery to do the job.

I think it'd be worth your trouble looking into how keys can be used to pull nodes like this (you may also have to bone up on generate-id as a crucial piece of this puzzle). As Mike hinted, the general problem you have posed (getting nodes between two other given nodes) is not an easy one, since it runs up straight against the parent-child "containment" representation of a document which XSLT is based on (it's only "pseudo-containment", if you like).

But techniques like this can help, anyhow.

Enjoy,
Wendell

At 05:09 PM 1/5/2004, you wrote:
Here's a bit more information (that I am quite sure everyone is sick of
by now, but I can't quite get to the end of it)...


======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================


XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list



Current Thread