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[(_at_)name=$n]"/>
I removed the test [(_at_)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
[(_at_)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