Article View: comp.text
Article #2878Re: Marking up 'Automatically' -anyone
From: Nick Carr
Date: Sun, 27 Dec 1992 22:46
Date: Sun, 27 Dec 1992 22:46
56 lines
3543 bytes
3543 bytes
In article <1992Dec25.230745.16019@tc.fluke.COM> 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 (info@xgml.com) 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
Technical Details
Message-ID:
<921227224658-100033.3271-DHM26-1@CompuServe.COM>Path:
arc1-ca.pugleaf.net!sparky!uunet!gatech!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!aun.uninett.no!nuug!ifi.uio.no!sgml.newsReferences:
<20186.2b362c76@ul.ie> <19921223.044835.214@almaden.ibm.com> <1992Dec25.230745.16019@tc.fluke.COM>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!gatech!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!aun.uninett.no!nuug!ifi.uio.no!sgml.news From: 100033.3271@CompuServe.COM (Nick Carr) Newsgroups: comp.text,comp.text.sgml Subject: Re: Marking up 'Automatically' -anyone Message-ID: <921227224658-100033.3271-DHM26-1@CompuServe.COM> Date: 27 Dec 92 22:46:59 GMT References: <20186.2b362c76@ul.ie> <19921223.044835.214@almaden.ibm.com> <1992Dec25.230745.16019@tc.fluke.COM> Lines: 56