Re: [xsl] why not match text()? (fork from "Novice Question - matching entire text children")

Subject: Re: [xsl] why not match text()? (fork from "Novice Question - matching entire text children")
From: "Imsieke, Gerrit, le-tex" <gerrit.imsieke@xxxxxxxxx>
Date: Tue, 21 Dec 2010 01:06:56 +0100
I didn't save this groups messages, but I remember someone saying on this list today that in 99.99 percent of all real-life stylesheets dont use text() matching. (Ill look that up tomorrow in the archives, but I think it was Wendell G. Carlisle (wink).

Being able to do upconversions is the single most valuable macrofeature of XSLT 2. In my daily life, text() is quite important:

find . -name \*xsl | xargs grep -ch 'text()' | sed -e 's/^/.+/' | bc | tail -1

yields the result: 2278. Try that in your home directory. Ok, there may be duplicates, for example stemming from multiply included svn externals or from generated stylesheets, or text() may be used outside of patterns, but this figure is somehow relevant. To attach a scale to this: there are `find . -name \*xsl | wc -l` = 1016 xsl files in my home dir. So approx. two text() per xsl.


On 21.12.2010 00:40, Wendell Piez wrote:

These all fall into the category of text processing or upconversion, not
tree processing. While XSLT 2.0 provides a nice set of tools for doing
this sort of thing, these are tasks that demonstrate the principle being
discussed precisely in the way they violate it.

That is, it's not the fact that it contains mixed content, but the fact
that your text isn't clean coming in, and has to be ameliorated as it
passes through, that makes these examples fall out.

It's also why in an advanced architecture we might also like to do this
kind of processing in separate transformations from formatting. Note
that these are things you often want to happen as data comes into your
data set, not as it goes out.


On 12/20/2010 6:05 PM, Syd Bauman wrote:
Wendell is absolutely correct, a lot of learning goes on 'round here
just "watching over each other's shoulders", which I don't get to do
as much as I'd like.

Watching this conversation, I found myself interested in how many
experts say there is rarely a need to match text nodes. I do that
all the time. Some examples include:
* transforming straight quotes to curly quotes
* conditionally changing "-" to en-dash or em-dash
* convert PUA characters to<tei:g> elements
* deal with soft hyphens
* ditching the punctuation that follows a<list>
* finding the character before a footnote

So I'm guessing either
a) there's a better way for me to be doing these things, or
b) those experts who spoke of the rare need for matching text()
either don't deal with data like mine -- TEI, i.e., mostly mixed
content --, or deal with so much more of it that my needs for
matching text() are, in fact, pretty rare from their point of view

I'm hoping someone will post the better way if it's (a). :-)

-- Gerrit Imsieke Geschdftsf|hrer / Managing Director le-tex publishing services GmbH Weissenfelser Str. 84, 04229 Leipzig, Germany Phone +49 341 355356 110, Fax +49 341 355356 510 gerrit.imsieke@xxxxxxxxx,

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

Geschdftsf|hrer: Gerrit Imsieke, Svea Jelonek,
Thomas Schmidt, Dr. Reinhard Vvckler

Current Thread