[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Mike,
At 02:13 PM 12/28/01, you wrote:
I don't have a solution to your question, but since a full discussion of it raises questions that are currently topics of other threads ongoing, I'm going to stick my neck out anyway. The theme is "should I try this in XSLT at all?" Only you know the answer, since it depends on your operating context.
I bet you Jeni could give you an XSLT solution, probably using some smart, albeit monstrous, recursive template (and maybe more than one pass over the data). I guess she's still wassailing, though, since we haven't heard from her this week. Dimitre might be able to apply his formidable functional programming methods to it and give you an answer -- while pointing out, possibly, that if XSLT were extended in one or two ways, it would be much easier to solve. Either way, I think it's clear this falls in the "teaching a dog to dance" category, at least as far as XSLT 1.0 is concerned.
This type of problem is easily solved with regular expressions, for which you will find support in a range of languages designed for text processing, such as Perl etc. But XSLT was not designed for text processing -- it's designed for node-tree transformations, not the same thing at all.
If I were facing this I'd look at writing an extension function in Java and using a Java XSLT processor such as Saxon or Xalan: then running this function on the nodes in question (such a function could either return a Boolean true(), or do string munging itself). An article cited earlier today makes a good case for this architecture. Mind you, I'm not a Java programmer -- but the very fact that I'd seriously take a look at this approach, while I *am* pretty well current with the state of the art in XSLT -- indicates how "unnatural" I consider the stated task to be for the language as designed.
Alternatively, I'd look at a whole different platform, such as Perl or Python, particularly if they have support for some kind of XML DOM (and they both do) that would free me from having to worry about parsing tags out of the text.
By suggesting this, I mean to take nothing away from the considerable contributions both of list members who are willing to push the edges of XSLT (among whom I might myself sometimes be counted), or of those like Dimitre who are demonstrating, to the great benefit of all of us, how more generalized approaches to programming can wrestle the language into tractability for tasks for which it was not originally designed (and for which even Dimitre will concede it is less than elegant).
But you know, this kind of job is precisely what the extensibility architecture is for.
If it's at all comforting, XSLT 2.0 is projected to support regular expressions: you're not the only one who'd like to use them.
(See http://www.javaworld.com/javaworld/jw-12-2001/jw-1221-xslt.html for that article.)
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Re: [xsl] Literal string question
|
Subject: Re: [xsl] Literal string question From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> Date: Fri, 28 Dec 2001 15:36:34 -0500 |
Mike,
At 02:13 PM 12/28/01, you wrote:
I would like to select all names that have initials not seperated by a space. Such as:
A.A. Peters
Could someone give me the syntax for searching for such a string?
I don't have a solution to your question, but since a full discussion of it raises questions that are currently topics of other threads ongoing, I'm going to stick my neck out anyway. The theme is "should I try this in XSLT at all?" Only you know the answer, since it depends on your operating context.
I bet you Jeni could give you an XSLT solution, probably using some smart, albeit monstrous, recursive template (and maybe more than one pass over the data). I guess she's still wassailing, though, since we haven't heard from her this week. Dimitre might be able to apply his formidable functional programming methods to it and give you an answer -- while pointing out, possibly, that if XSLT were extended in one or two ways, it would be much easier to solve. Either way, I think it's clear this falls in the "teaching a dog to dance" category, at least as far as XSLT 1.0 is concerned.
This type of problem is easily solved with regular expressions, for which you will find support in a range of languages designed for text processing, such as Perl etc. But XSLT was not designed for text processing -- it's designed for node-tree transformations, not the same thing at all.
If I were facing this I'd look at writing an extension function in Java and using a Java XSLT processor such as Saxon or Xalan: then running this function on the nodes in question (such a function could either return a Boolean true(), or do string munging itself). An article cited earlier today makes a good case for this architecture. Mind you, I'm not a Java programmer -- but the very fact that I'd seriously take a look at this approach, while I *am* pretty well current with the state of the art in XSLT -- indicates how "unnatural" I consider the stated task to be for the language as designed.
Alternatively, I'd look at a whole different platform, such as Perl or Python, particularly if they have support for some kind of XML DOM (and they both do) that would free me from having to worry about parsing tags out of the text.
By suggesting this, I mean to take nothing away from the considerable contributions both of list members who are willing to push the edges of XSLT (among whom I might myself sometimes be counted), or of those like Dimitre who are demonstrating, to the great benefit of all of us, how more generalized approaches to programming can wrestle the language into tractability for tasks for which it was not originally designed (and for which even Dimitre will concede it is less than elegant).
But you know, this kind of job is precisely what the extensibility architecture is for.
If it's at all comforting, XSLT 2.0 is projected to support regular expressions: you're not the only one who'd like to use them.
Regards, Wendell
(See http://www.javaworld.com/javaworld/jw-12-2001/jw-1221-xslt.html for that article.)
====================================================================== 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 ======================================================================
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
| Current Thread |
|---|
|
| <- Previous | Index | Next -> |
|---|---|---|
| [xsl] Literal string question, Mike Ferrando | Thread | Re: [xsl] Literal string question, Mike Ferrando |
| Re: [xsl] Re: Assignment no, dynami, Mark Nahabedian | Date | Re: [xsl] xsl-fo:header, body, and , Wendell Piez |
| Month |