RE: [xsl] XPath to select based on attr = same attr of an ancestor

Subject: RE: [xsl] XPath to select based on attr = same attr of an ancestor
From: Syd Bauman <Syd_Bauman@xxxxxxxxx>
Date: Thu, 17 Jul 2008 10:13:57 -0400
HC> This seems to work:
HC> [separate test for condition after having matched any <foreign>]

KH> foreign[@lang = ancestor::*[@lang][1]/@lang]

MK> foreign[@lang = (ancestor::*/@lang)[last()]]

Thank you very much, gentlemen! I have in fact gotten the
transformation I needed working. (Yay!) I would, however, like to
understand why
   foreign[@lang][ancestor::*[@lang]][1][ ./@lang = ./ancestor::*[@lang][1]/@lang ]
doesn't work. I realize now that the first set of predicates are
unnecessarily trying to select only those <foreign> elements for
which the test might make sense (and the first [1] predicate is
useless, no?), but even so, that means this XPath boils down to
   foreign[ ./@lang = ./ancestor::*[@lang][1]/@lang ]
which looks an awful lot like the KH construction, above. Seems that
if you remove my redundant "./" steps, it's the same.

And am I right that the difference between the KH and MK construc-
tions are that the former is looking up the ancestor axis for the
first hit, whereas the latter is looking down the ancestor axis for
the last hit? Is one "better" than the other in any significant way?

KH> ... since there are more semantics for xml:lang= ...

Heh! Interesting uses of the term. You, I presume, mean that there is
more capability to handle xml:lang= natively in XPath 1.0. But it
turns out that we at TEI spent some significant time wrangling our
hands over whether to switch from using tei:lang= (as we had in P4) to
using xml:lang= or not. The main argument in favor of sticking with
tei:lang= was that it is more semantically rich than xml:lang=. The
arguments in favor or switching to xml:lang= were that it's what
everyone else will be using, and there's nice software support (like
the XPath lang() function).

In the end, we decided to go with xml:lang= in P5. I presented a
paper about this particular decision at ALLC/ACH 2004 (G&ouml;teborg,
Sweden), the abstract of which is available at 

In retrospect, now that BCP 47 has replaced (RFC 3066 which had
replaced) RFC 1766, and given that we did come up with a mechanism
that permits more nuanced semantics for language "tags", I think it
has working out pretty well.

Thanks agian.

Current Thread