Re: Use of ML Tagged Docs on PC?

[Chet Ensign <Chet_Ensign%LDS -at- NOTES -dot- WORLDCOM -dot- COM>]

Kevin Montgomery wrote:

> Documents are generated on  the mainframe by an automatic system
> that reads a control file to selectively combine bits of text from databases
> with other text files stored on a library disk.

That's very cool.

> (Note that both our documentation group and our customers have access
> to the mainframe files, databases, and software.)

That is even cooler! Being able to offer real-time information access to
customers is a terrific benefit and one that few manufacturers are in a
position to do.

> The process yields a text file tagged with a proprietary markup language
> loosely similar to SGML.

When you say this, are you assuming that SGML is a predefined set of tags? SGML
is a formalized method for defining markup languages. You may not have followed
the method -- that is, you may not have written a formal DTD to describe your
markup language -- but that doesn't necessairily rule out the benefits. Sounds
like what you have is a well defined generic markup language and that was the
precursor to SGML.

> Would anyone be willing to comment on the use of an SGML or HTML viewer to
> view the encoded text files directly on either a PC or on the mainframe
> (assuming conversion from the proprietary markup language to a standard
> language)?

This is why I mention the "proprietary" issue. This is certainly the most
direct way to go and one that you may be a very good position to do.

You could choose to use SGML browsers, such as DynaText from Electronic Book
Technologies, Open Text from the company of the same name, or Explorer from
SoftQuad. Doing that would enable you to use the output of your system
(almost?) directly for CD-ROM delivery. At least in the case of DynaText and
Explorer, you would have to write a DTD to formalize your markup. I'm not
certain about Open Text. However, assuming you have not done anything too
off-the-wall in your markup language, that would not have to present an
insurmountable barrier.

For HTML browsers, you would need to convert your markup to HTML. Downside;
this requires a conversion step of your data. But if your data is in
predictable format -- and from the sound of it, it is -- this would be a
program that you would write once, then use to reprocess the data
automatically. Very doable. You could use a public-domain tool like AWK, PERL
or REXX to do the conversion (sans the benefits of a DTD), or, if you chose to
write a DTD, you could use a tool like Omnimark or Belise with their integrated
parser to really do some crunching of the data.

Both these solutions will support navigational enhancements relatively easily.
Putting a TOC and/or an index on top of predictably structured information can
be done by an autopilot process and , if there are markers of some sort in the
body of the content, you could cross-reference automatically as well.

Finally, you could convert into the flavor of RTF required by WinHelp or MS
Multimedia Viewer. Again, on the assumption that your source is highly
structured, this is a one-time programming task. The key advantage you have
here is that your source documents are in a highly structured form. You can
make your pick of output/display engine.

Best of luck. When you say you want to do what's best for your customers, you
are stating the key committment that is required for a project like this.  Way
to go!

Best regards,

/chet

Chet Ensign
Director of Electronic Documentation
Logical Design Solutions
571 Central Avenue                      http://www.lds.com
Murray Hill, NJ  07974                  censign -at- lds -dot- com [email]
908-771-9221 [Phone]                  908-771-0430 [FAX]