RE: Frame+SGML?

["Peter Ring" <pri@xxxxxx>]

The one thing about structured Framemaker+SGML documents that appeals most
to me is your first point. I work part-time as a technical writer and
appreciate very much the conveniences of structured documents: focus on
contents while you write, and much easier to rearrange structure.
  But I'd also like to stress the other part of the equation: given a
structured document and sophisticated formatting rules, it is much cheaper
(in terms of manual labor) to obtain a typograhically pleasant and correct
result.
  Instead of abusing markers and silly 'invisible' paragraphs, you can use
attributes to carry information not present litterally in the text. And you
can set up the EDD to automatically make those small adjustments that
otherwise call for manual overrides or a paragraph catalog the size of a
phonebook.

I wonder if these benefits of FrameMaker+SGML would be more widely known if
the initial price were not so steep: one FrameMaker+SGML license is $2K, and
then you need to have someone develop an EDD. It is nice that Adobe
published a collection of unstructured templates for various types of
documents, but there's also a dire need for good examples of structured
templates.

I'd like to add that the EDD has shortcomings. It is almost a programming
languages, except it lacks those general features of most programming
languages that enable you to extend the language itself. Why is it not
possible to save numerical or string values for later reference? Why can't I
evaluate a simple expression in order to calculate a value? Why can't I
define new data types and new functions?
  In my day-time work, we had to find a way around these shortcomings for a
particular product (a periodical with a somewhat complicated layout). We
simply don't use an EDD and read/write rules. First, we investigated using
the FDK to add the features that we needed, but found it too cumbersome.
Now, we've taken to use OmniMark to translate SGML source files to MIF; this
looks like a general solution that is easy to maintain. Sadly, this also
reduces FrameMaker+SGML to a page composition engine.

Kind regards
Peter Ring



> -----Original Message-----
> From: Dan Emory [mailto:danemory@primenet.com]
> Sent: 17. juni 1999 00:34
> To: Peter Ring; joanne grey; Free Framers
> Subject: RE: Frame+SGML?
>
>
> Peter: Although many of your points are well-taken, I contend that FM+SGML
> should be considered for many enterprises who aren't currently
> interested in
> SGML. Here are some of the reasons I say that:
>
> 1. It is a great productivity enhancer for writers. Virtually every
document
> of any consequence that I produce in my practice are created in FM+SGML,
> using an EDD of my own design. The EDD takes care of all formatting
> automatically, allowing the writer to concentrate on content rather than
> style. In my experience, structured document authoring halves the required
> writing time. Also, the interactive structure view is a real boon when
> rearranging text, tables, or whatever. Making revisions is also much
faster.

<snip>

>
> At 11:30 PM 6/16/99 +0200, Peter Ring wrote:
> >If your customer has
> >
> >
> >And maybe FM+SGML is a good idea without SGML; many formatting
> >tasks can be automated if you work with structured documents.
> >You don't have to involve SGML at all to get this advantage.
> >Dan Emory has a paper that illustrates how a complex layout
> >can be implemented using a structured document.
> >

<snip>

> >Expect also a lot of nice and obvious solutions to problems
> >that you used to solve with dirty, fragile, and complicated
> >tricks in unstructured documents.


** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **