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