Anders Svensson wrote:
> Wow... I just barely understand it, but it seems to work!

Whew. I was afraid that by posting that at 5:30 in the morning,
I'd be making apologies for it today :)

> Just a couple of questions
> In the following statement:
>   <xsl:variable name="ignorableElemsToTest" select="$elementsToIgnore[@name=$n]"/>
> I removed the test [@name=$n]
> I didn't understand what it was for, there wasn't any variable named n...

Yes, just left over from a previous version of the code... should have been
[@name=name()] but it's probably not necessary, given the way I structured the
xsl:if tests. I was thinking it would help prevent a match when there is more
than one ignorable element specified with the same attribute names.

> Also, I guess this statement
>       <xsl:if test="$thisElement/@*[name()=current()/@name]=current()/@value">1</xsl:if>
> coupled with this statement
>   <xsl:if test="not(string($thisElementIsIgnorable))">
> checks for the value 1 (sort of boolean?) or not. But if so, why is the string function used? Shouldn't one need some sort of numerical value? Like I said, it works, I just want to understand why :-)

When you bind a variable by specifying the value in the content of the
xsl:variable element, rather than via an XPath expression in the select
attribute, the value is always a result tree fragment consisting of a root
node, plus children that are whatever other nodes you generated. In this case
we end up generating 1 or more text nodes containing "1" (and they get
normalized into a single node with text "1" or "11" or "111"...). The fact
that I chose "1" as the string was immaterial; it just needed to be something
that would result in the RTF having a non-empty string-value. The reason for
the string() is because an RTF alone always tests as true, because it always
has a root node.

Mike

-- 
  Mike J. Brown   |  http://skew.org/~mike/resume/
  Denver, CO, USA |  http://skew.org/xml/

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