Re: XSLT and Text Processing Languages

Subject: Re: XSLT and Text Processing Languages
From: Dan Vint <dvint@xxxxxxxx>
Date: Wed, 6 Sep 2000 16:00:23 -0700 (PDT)
> 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++?

It is avaialbe on the most useful Unix and PC systems.

>  - 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

OmniMark was actual designed for non-programers - which ususally makes th
programmers complain about the wierd syntax ;-)

>  - 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 can embedd/link to your application, but OmniMark would run the show.

 - Current version is really 100% useful in XML mode for documents without
DTDs. v6 is supposed to handle this better.

>  - 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

You need to work with the DTD and entities
You need more power to include reqular expression sorts of find rules along
with processing based upon the element syntax
You want to validate your XML on the way out and use the parser responses
(error messages) to help trigger output
You don't want to build and use the entire document tree, but want a SAX like
event triggered environment that doesn't require as much memory

> 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:

 XSL-List info and archive:

Current Thread