[Date Prev][Date Next] [Thread Prev][Thread Next]
[Date Index] [Thread Index] [New search]

Re: Frame+SGML Tutorial?

At 06:08 PM 12/22/99 +0100, Chris Despopoulos wrote:
>I feel the need to reply/enter into one of those
>nearly-religious-hassle-fests.  Stop me before I type again!
>Dan Emory said:
>     There's a true story about some outfit (might have
>     been a think tank) which
>     commissioned five of the top SGML experts to
>     independently develop document
>     type definitions (DTDs) for a popular magazine (I
>     seem to recall it was
>     either The New Yorker or Atlantic Monthly).
>It may be a true story, but from here it sounds very much
>like Rush Limbaugh saying "I'm not making this up folks!"
>when he says there's more old-growth forest in N. America
>today than in the 17th century...  OK, sorry about the
>flame-bait, but I just can't resist a chance to slag the old
It is a true story. I read it some years ago in (what I vaguely recall as) a
scholarly treatise on SGML. It probably wasn't a think tank that sponsored it,
but I think the sponsor's premise was valid, namely: If SGML is a valid
discipline, then the DTDs should have closely resembled each other. They
didn't, and that was the point made in the article that included the story.
>I think there *are* books covering DTD design.
Perhaps there are some on DTD design, but there are absolutely none
on the unique aspects of EDD design (e.g., how to design format rules, or
how to design an EDD so document instances can be successfully imported and
exported without the need for API clients).
>EDD design and
>DTD design are the same problem, though.  Whatever you know
>about one transfers to the other.  The Dev Guide shows how
>to make that transfer.
But there are aspects of EDD design which might make the resulting content
models differ from those that would be used to develop a new DTD. For
example, a graphic element in an EDD cannot have any children, whereas it is
common practice for graphic elements in DTD's to have them. There are also
aspects relating to the formatting of imported tables and cross-references
that are unique to FM+SGML, which often require content models which differ
from those that would typically be used in DTDs.
>And it *is* a good idea to print the Maker+SGML Dev Guide.
>But you need to do more than read it; you need to isolate
>the categories of SGML/Maker+SGML transfer that are
>important to you and actually experiment with them.
The issuet of SGML import/export, using read/write rules, is
another subject entirely, which I did nopt address in my original post. To
the novice, it's probably even more baffling than EDD design.
>And one last bit of advice...  Authoring in a validated,
>structured environment is different than doing it
>free-form.  It takes more effort on the part of the
I'd agree with your conclusion in the case where the EDD is derived from a
typical "institutional" DTD. But if more effort is needed in the case where
the structure design was initially done in the EDD, then I would advise
taking another look at the EDD, because it is usually possible to
substantially increase authoring productivity compared to authoring
unstructured Frame docs. That, at least, has been my experience. In many
ways, authoring a structured doc in FM+SGML takes less effort, because
almost all of the formatting burden is removed, allowing the author to focus
on content and structure. Also most authors quickly adapt to using the
element catalog and structure view for guided editing, and like it much
better than trying to create structure with paragraph tags.
     | 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
---Subscribe to the "Free Framers" list by sending a message to
   majordomo@omsys.com with "subscribe framers" (no quotes) in the body.

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