This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Literal string question


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@mulberrytech.com
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]