[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
[Recent Entries]
[Reply To This Message]
Re: why not match text()? (fork from "Novice Question
Subject: Re: 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.
-Gerrit
On 21.12.2010 00:40, Wendell Piez wrote:
Syd,
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.
Cheers,
Wendell
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, http://www.le-tex.de
Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930
Geschdftsf|hrer: Gerrit Imsieke, Svea Jelonek,
Thomas Schmidt, Dr. Reinhard Vvckler
|
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format
RSS 2.0 |
|
Atom 0.3 |
|
|