Re: [FrameSGML] Re: Frame+SGML Tutorial?

[Marcus Carr <mrc@xxxxxxxxxxxxxx>]

Is it just me, or is hard to keep track of which forum this thread exists in? Was
there really a need to break FrameSGML questions into their own list?

Dan Emory wrote:

> 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.

I agree, but I consider them to be shortfalls in FrameMaker+SGML. Of course, that
doesn't alter the fact that you have to deal with them

> >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
> >authors.
> 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.

I agree all the way. The conventional art of designing documents involves a tiny
amount of analysis being done each time a new object (title, paragraph, image,
etc.) is entered, whereas with SGML most of that analysis is loaded to the front
of the project. The authors need to be given an opportunity to express their
collective views and those views need to be reflected in the structure. While
authoring documents, the authors should rely on the agreements reached during the
analysis stage - the structure allows them to do so. If they find it to be
deficient, they should say so, but eventually they should all be satisfied that
they have something workable, even if they didn't back all of the decisions 100%.

If you find that authoring to a structure is a substantial overhead, you should
examine the structure. It's possible that you could benefit from the creation of a
structure aimed at making authoring simpler and that a post-process could convert
the data to the destination format. Issues such as augmenting documents with
database information and otherwise dynamically rendered documents will likely mean
that an author having a view of the data only vaguely resembles what the the user
sees will become much more common in the future. I believe that this also has the
potential to become a problem for technical writers, but that's another topic...


--
Regards,

Marcus Carr                      email:  mrc@allette.com.au
___________________________________________________________________
Allette Systems (Australia)      www:    http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
       - Einstein



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