[
Lists Home |
Date Index |
Thread Index
]
XSLT and XPath questions would be better posted to the following list:
http://www.mulberrytech.com/xsl/xsl-list
There are a number of subscribers who would enthusiastically respond
to such questions.
There is also an *excellent* XSLT FAQ at:
http://www.dpawson.co.uk
At 2005-10-06 07:51 +1000, Jordan Howarth wrote:
>I recently used a variable referencing a node-set (x) as a predicate
>expression. I was expecting that the initial node-set (y), to which the
>predicate was applied, would be filtered as if each node from y was
>being compared to the node-set x.
False.
>What I think I observed was that y was
>being compared to x as a complete node-set.
False again.
>To be more explicit, I was applying the preceding-sibling axis:
>
>For the following node-set
>
> <xsl:variable name="subnodes"
>select="allnodes['simple-predicate']"/>
>
>I applied two strategies using a given node from "subnodes" as the
>context node:
>
>(a) simply add "subnodes" as the predicate
>
> <xsl:variable name="preceding"
>select="preceding-sibbling::mynodetest[$subnodes]"/>
The above will include all preceding sibling elements named
"mynodetest" if the $subnodes node-set variable is non-empty.
>(b)explicitly define a node by node-set comparison
>
> <xsl:variable name="preceding"
>select="preceding-sibbling::mynodetest[self::* = $subnodes]"/>
The above will include each preceding sibling element named
"mynodetest" whose string value is in the set of string values of the
nodes of the $subnodes variable.
>I expected the results from (a) and (b) to be identical.
They are quite different.
>Can someone please explain?
A node-set predicate evaluates true when non-empty ... period. In
your first example, if your node set variable is non-empty they the
predicate evaluates true for each of the preceding siblings, so all
of them get included in the result set.
Comparison of two node sets initializes the result to false and then
does the equivalent of: compare the string value of the first member
of the first node set with the string values of each of the values of
the nodes in the second node set, and if all of the comparisons are
false, it then checks the string value of the second member of the
first node set with the string values of each of the nodes in the
second node set, and so on, until either it runs out of comparisons
(in which case it returns false), or any one of the comparisons
returns true (in which case it returns true). I say "does the
equivalent of" because it can do the comparisons in any order it
pleases; the return is false if none of the comparisons are true and
the return is true if any of the comparisons are true, so it doesn't
matter in which order the processor does the comparisons. There is
no way of being told *which* of the comparisons returns true.
In your second example, it is not checking membership of the first
node in the second node set, it is checking the membership of the
value of the first node in the values of the nodes of the second node
set. Not what you want.
To check membership you could do the following:
select="preceding-sibling::mynodetest[count(self::*|$subnodes) =
count($subnodes)]
Because of there being no duplicates in a node set, if the count of
the members of the union of the given node with the variable is equal
to the count of the members of the variable, then the given node must
be a member of the variable.
I hope this helps.
. . . . . . . . . . Ken
--
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/x/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/x/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
|
