Richard Tobin wrote:
Quote:
In article <1158694968.129737.260270@k70g2000cwa.googlegroups .com>,
Jean-François Michaud <cometaj@comcast.netwrote:
>
Quote:
../CELL[1] actually refers to the content of CELL[1] instead of
refering to a unique identifier specific to the first child of the
parent. Who?!?! What??!?.
>
This is, of course, what you usually want. It's much more common to
compare the content of nodes than to compare them for identity.
Hmmm. It seems upside down to me.
Quote:
Quote:
A freak case emerged when of course, 2 different cells within the same
row had exactly the same content.
>
That's not a freak case, it's perfectly normal.
According to what I read of the spec it seems to be. It seems to me
though as if it should be the other way around. Or at least, I believe
it should be made explicit weather we are referencing the node itself
or its content, giving us the choice of dealing with structure or with
content without having to scope into esoteric programming. As it is,
the XPATH expression gives me the impression that we are talking about
structure as opposed to content; it so happens to be the other way
around we attain content by talking about structure. Do XPATH
expressions in 'select' and 'match' behave the same way? If this isn't
the case, then it seems we have inconsistent behavior. Two XPATH
expressions talking about 2 different things. One talking about
structure whereas the other talks about content.
Quote:
Unfortunately there's no "natural" way to determine node identity in
XPath (at least, in XPath 1). Two unnatural ways are:
>
generate-id(node1) = generate-id(node2)
>
and (probably more efficient):
>
count(node1 | node2) = 1
Thanks for the tip.
Regards
Jean-Francois Michaud