> XSLT 2.0 improves matters slightly, but still it isn't really the right

> tool for this task ... at least, not in most cases. (I can see where you

> might want to use XSLT to do this if you're trying to do it in an

> environment specialized for XSLT; I might write a stylesheet if I was

> doing this on a Datapower appliance, for example.)



This task is trivial to do in XSLT.



In fact, it has been shown that many much more complicated text processing 
tasks are performed quite efficiently using FXSL 2.0 and XSLT 2.0. The 
solutions typically are compact and easy to understand. Just a few examples:



  Spelling checking Othello with speed of more than 500 words per second.

  www.---.com



  Producing a concordance of the Bible (New Testament)

  www.---.com



  Text justification.

  http://www.thethameens.com/lists/xsl-list/archives/200504/msg01314.html

  http://sourceware.org/ml/xsl-list/2001-12/msg00651.html



  Finding anagrams.

  http://dnovatchev.spaces.live.com/Blog/cns!44B0A32C2CCF7488!357.entry



  Parser for LR(1) context-free languages.

  http://dnovatchev.spaces.live.com/blog/cns!44B0A32C2CCF7488!367.entry





Cheers,

Dimitre Novatchev.







"Joseph Kesselman" <keshlam-nospam@c...> wrote in message 
news:<47547105$1@kcnews01>...

> 1) XSLT 1.0 expects XML files as input, and so won't operate directly on

> an ASCII file. You might be able to kluge around that by referencing the

> plaintext file as an External Parsed Entity from a front-end XML file,

> but then the ASCII would have to obey all the rules for XML parsed

> character content (in particular escaping < and > and & characters).

>

> 2) String processing in XSLT is possible, but that really isn't what

> XSLT is set up for. You're likely to wind up having to write some

> recursive logic for even fairly basic string-search-and-replace tasks,

> since XSLT is nonprocedural and doesn't have simple character-scan

> loops. (See the XSLT FAQ website for examples of how to do that kind of

> task.)

>

> XSLT 2.0 improves matters slightly, but still it isn't really the right

> tool for this task ... at least, not in most cases. (I can see where you

> might want to use XSLT to do this if you're trying to do it in an

> environment specialized for XSLT; I might write a stylesheet if I was

> doing this on a Datapower appliance, for example.)

>

> But in general, I would suggest that you write a bit of simple code in

> your preferred programming langauge, using an off-the-shelf XML

> serializer for that language to ensure that the output syntax is

> correct, and write your own string tokenization and data extraction 
> routine.

>

>

> -- 

> Joe Kesselman / Beware the fury of a patient man. -- John Dryden