NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/text/1501

Internet Message Format | 1992-12-27 | 3.4 KB

Xref: sparky comp.text:1501 comp.text.sgml:1239
Path: sparky!uunet!gatech!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!aun.uninett.no!nuug!ifi.uio.no!sgml.news
From: [e-mail] (Nick Carr)
Newsgroups: comp.text,comp.text.sgml
Subject: Re: Marking up 'Automatically' -anyone
Message-ID: <[e-mail]>
Date: 27 Dec 92 22:46:59 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Lines: 56

In article <[e-mail]> Gary Benson writes

> Another alternative is to code it up yourself. Here at Fluke, we have
> been standardizing our input file format since the days of typesetting
> made it seem like a good idea to give consistent input to the
> typographer.

Although we are reasonably new to using SGML in actual production (our
background is as a technical publishing bureau using all the usual tools
- Frame, Ventura, dbPublisher etc), it didn't take long to realise that
main problem was going to be getting text out of arbitrary formats into
something that we could validate then back into arbitrary formatting
tools. In addition to solving this, we wanted a tool that we could use
to manipulate files - something that could work like a database report
writer. As a bureau we have no such thing as standard input. We get text
in all sorts of formats (including hardcopy), syntaxes and consistencies
(or lack thereof).

Flexibility is important to us, but so is productivity. For several of the
jobs where we use SGML, the clients do not even know (or care) what it is.
Because they are not willing to pay for the extra processing, the cost of
SGML has to be recouped by us over the life of the project.  Of course
SGML offers us the same benefits as any other users. It enables us to
automate formatting, better cope with changes to document specifications
and prepare our data in an application neutral format then choose our
formatting engine once we understand the data better. So providing that
the SGML component of the job is not disproportionally expensive we think
that the investment is worth it.

However, we do not have a strong programming background. While we have
alot of experience with text macro languages, there are no serious C (or
equivalent) programmers here - so writing anything ourselves wasn't even
considered. Based on these requirements, it seemed that the only tool
suitable for us was OmniMark from Exoterica. OmniMark allows us to write
(and maintain) comprehensive translators quickly enough that the cost of
SGML doesn't outweigh the benefits. For organisations that don't need to
handle the diversity of data that we do or who can enforce some markup
standards on authors, OmniMark may be more than you need. But if you need
a heavyweight tool, you should mail Exoterica ([e-mail]) and ask for
a Sampler. The Sampler's have an OmniMark run-time license with several
different example files, scripts etc.

Just to prevent any misunderstandings, I should state that we are now
working with Exoterica to represent OmniMark in the Asia Pacific region so
feel free to disregard my opinion about the product. However, for what it
is worth, we came to the product as users and that is primarily how we are
involved with it. Distribution was similar to the old Remington electric
shaver commercials - "I liked it so much I bought the company".

Nick Carr
Allette Systems
Level 4, 301 George St
Sydney  NSW 2000
Australia
Ph 612 262 4777
Fx 612 262 4774