Some while back, Lou Burnard wrote:
> Here's my personal subjective off the top of pate comparisons:
> OMNIMARK SGMLS-PM
> price Large Zero
> feature set large but closed unlimited 
> learning curve steepish flat for Perlers;
> steep for others
> performance excellent good
> SGML-support full full 
> ESIS access full (?) limited 
>  Omnimark uses its own programming language which, to my eyes, looks
> a little strange. SGMLS-pm uses perl5 which to some eyes looks even
> stranger, but which has the virtue of being very very widely supported.
And I added -- but only, I find, on doing my filing, to him, which is
why I'm sending it to the list now...
Yup, Omnimark's a strange language. It has some very neat hacks for
doing the sort of things one turns out to want to do in conversions,
but, in my eyes, that's no reason for making the more conventional
features of the language (flow control, looping...) so unconventional in
Omnimark's closed nature is currently, as far as I am concerned, its
main drawback: you can't, for example, whip up an Omnimark program which
listens on a socket. Such things are a piece of cake (possibly the
sticky sort which makes a mess of your clothes) with a perl-based tool.
Omnimark version 3, due, according to http://www.exoterica.com/nox/
(welcome, belatedly, to the Web, Exoterica), in Q3 1996, may overcome
this limitation by providing an API, but the online information does not
explicitly promise this. When I was using Omnimark in anger late last
year, Exoterica support people told me that an API was in the works, and
that this would allow the use of C, C++, or whatever, in a program to do
things which Omnimark couldn't.
Another aspect of Omnimark which is annoying in this day and age is that
it is exclusively command-line driven, and, while internally it has a
nice event-driven architecture, those events can come ony from
information it finds while processing files. What am I getting at?
Omnimark has no GUI aspects whatever. Without an API, one cannot graft
one on (at least, not easily and/or prettily), and this makes Kmnimark
applications clunky and difficult to control. The information on the
Web site has a diagram showing the (next generation) Omnimark engine
interfacing to Visual Basic, so maybe a fix for this shortcoming will
soon hit the streets. I certainly hope so.
>  SGMLS-pm only keeps track of the ESIS tree as it steps sequentially
> through the document. So forward references (e.g.) require special
> treatment -- using either a supplied set of stack-handling routines or
> multiple passes through the file. I believe that Omnimark does the same,
> but packages it more transparently.
Well, make that translucently: you still have to do some work, but, yes,
there are useful hooks and hacks.
One more point. Omnimark's documentation is really bad. Not only is it
the archetypal computer language manual describing each feature of the
syntax in isolation without saying how they hang together, but also
newer features are described in a separate addendum which one has to
read while mentally keeping a note of how it affects the main manual.
And the indexes are not much help. Not even the Quick Reference guide
is much help. The only way to learn is by example on Exoterica's
training courses, which are both good and cheap. And, when you get into
trouble, RTFM is generally not good advice: it's better to call support
-- which is cooperative, knowledgeable and quick. But neither the
both good and cheap. And, when you get into trouble, RTFM is generally
not good advice: it's better to call support -- which is cooperative,
knowledgeable and quick. But neither the courses nor the support make
up for the horrible documentation.