Re: XSLT and Text Processing Languages

Brand_Niemann@xxxxxxx writes:

 >  So my question is the following: Does anyone have any feedback of
 >  when and where they would recommend using XSL/T, instead of
 >  Omnimark or any other text processing language?

in some ways, who cares what tool you use, if it does the job? but I
suppose XSL is the answer if any of the following apply (in no special
order):

 - you want the rendering done in a browser which does not implement
     Omnimark (none, I assume)
 - you need scripting portable across all platforms. is there Omnimark
    for all platforms for which there is Java or C++?
 - you must work with tools for which you have the source
 - you think you can persuade non-programmers to write simple XSL but
    not weird Omnimark
 - you want to embed your processing in your application. can Omnimark
    be linked into your own code, as most XSL processors can? i dont
    know.
 - you dont deal with vast files today

no doubt others can add to this list. or correct my mistakes

the list of reasons why you *would* use Omnimark include 

 - you need speed
 - you trust a more mature language
 - you have big files to process
 - you like a more traditional language
 - you have trained programmers

and I assume there are more

I would certainly hesitate to offer a hostage to fortune by suggesting
that there are jobs which only one of the two languages could cope
with. you can almost certainly, with greater or less elegance, solve
any problem with both. whether the solutions are always *sensible* is
another matter. I wrote a KWIC concordance generator in
XSLT. possible, but was it wise?

Sebastian Rahtz


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list