Re: Frame + SGML: is it for me?

[Richard Phillips <rgphill2@xxxxxxxxxxxx>]

Dan Emory wrote:
> 
> At 07:35 AM 7/9/99 -0400, Richard Phillips wrote:
> >
> >Having had some exposure to (Frame+SGML) I may be qualified to add a
> >remark or two.
> 
> >Comparing it to pure Frame, it may offer advantages to
> >large companies that deploy writers in battalions and turn out documetns
> >in very large numbers.
> =======================================================================
> Not so. I use an EDD I've developed in my practics to produce almost all
> documentation. Although FM+SGML can also work just like vanilla FrameMaker
> when you want it to, but I use the structured approach because it nearly
> doubles the speed at which I can work. I don't have to worry about
> formatting, because the EDD takes care of it for me. Most text container
> elements in that EDD include formatting attributes which allow me to quickly
> modify the default format specified by the EDD.

==========================================================
PHillips

POInt taken, but I'm having a hard time seeing why SGML gives you such a
huge productivity gain over vanilla Frame. I mean, with Frame alone, you
design your own template (or a linited set of templates) and use that
template over and over. Just why and how does SGML give you such a huge
gain over that?

==========================================
> ====================================================================
> >
> >It forces the writer to organize his work into certain pre-defined
> >structural entities with strict rules about the transitions between
> >them.
> ===================================================================
> True, but the structure need not be rigid. It depends upon the EDD/DTD. If
> you're not required to conform to an "industry standard" DTD, the EDD
> structure can be made as loose as you want it to be. Where a given
> mini-structure (say a captioned figure) has multiple elements, the EDD can
> work almost like a macro that inserts the elements in their proper sequence.
> ======================================================================
> >
> >The "advantages" are two-fold:
> >
> >(1) It tends to make all of an organizations document look alike.
> ===================================================================
> Not so. A single EDD/DTD can define different structure and formatting for
> different document types, and further variations are possible by creating
> multiple templates for the same EDD. My paper (available as a PDF document)
> entitled "FM+SGML Information Design" explains in detail how this can be done.
> ======================================================================
> >
> >(2) It makes it possible to grab a large block from one document and
> >drop it seamlessly into aother document.
> ==================================================================
> And that's not to be sneezed at. Information reuse and document repurposing
> are vital capabilities, and FM+SGML excels at it.
> ==================================================================
> >
> >Hated it, myself.  Can't stand having my creativity stifled.
> >
> >===============================================================
> Oh well. For you creative types who want to dawdle for hours over each page,
> there's always PageMaker and Quark.

========================================================
dick Phillips

OK, I'll be honest and confess that my problem wasn't so much SGML as it
was the &*^&$$#@@!()* editors. Silly sods refused to compromise and do
things my way.
> ======================================================================
> What hasn't been mentioned on this thread is FM+SGML's capability to
> function as a semi-automated style guide for both structure and formatting.
> And, by re-importing the template's element definitions and formats into a
> finished document the style guide is completely enforced, including the
> elimination of every single format override. The authoring and quality
> assurance time saved by this capability alone is worth the trouble of using
> a structured document approach, even if you have no SGML requirement.
>      ====================
>      | Nullius in Verba |
>      ====================
> Dan Emory, Dan Emory & Associates
> FrameMaker/FrameMaker+SGML Document Design & Database Publishing
> Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com
> 10044 Adams Ave. #208, Huntington Beach, CA 92646


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