[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
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.
On 12/20/2010 6:05 PM, Syd Bauman wrote:
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: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> Date: Mon, 20 Dec 2010 18:40:35 -0500 |
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). :-)
-- ====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] why not match text()? (fo, Imsieke, Gerrit, le- | Thread | Re: [xsl] why not match text()? (fo, Imsieke, Gerrit, le- |
Re: [xsl] Novice Question - matchin, Wendell Piez | Date | Re: [xsl] why not match text()? (fo, Imsieke, Gerrit, le- |
Month |