Re: questions regarding +SGML in relation to DOD Class 2 DTD

[Marcus Carr <mrc@xxxxxxxxxxxxxx>]

Al Friend wrote:

> This is a multi-part message in MIME format.

... which is at least annoying, and may possibly be the reason for your bounces, but
that's another issue...

> This is Al Friend, a relative newbie at both FrameMaker and +SGML -
> I've taken basic authoring courses in both, but I'm now getting in
> over my head. I have a DOD manual, written originally in Word,
> brought over into FrameMaker. I've got it to where it will print fine in
> FM. Now I need to get it into SGML!

That's an interesting workflow - did you consider the other route, of converting the
Word file to SGML, then loading it into Frame+SGML? Without knowing the magnitude of
the task, I'm only speculating - I just wondered if you had considered that
approach.

> I'm now on my own to learn how to do this. That's OK, but are
> there people out there who can work me thru some snags?
>
> Example: I'm adding structuring to the chapters of my book. How
> can I put the tables within paragraphs? It doesn't make logical sense
> in the context of my document to go back to the chapter level to
> insert a table, but that's the only place the thing will let me put them!

That's a snag of a different nature, not related to Frame in any way, but I can
understand your perplexion. The problem is that the relationships of the elements is
something that was established and codified during the analysis leading up to the
creation of the DTD. While I haven't looked at US DoD DTDs for about six years, I
was involved with the analysis and creation of the Australian CALS implementation
(25 DTDs, based on the US DoD CALS implementation), so well understand the
motivation for decisions that may appear odd to the uninitiated. (Please excuse the
excessive acronyms; they're SDP - err, standard defence policy.)

Without seeing the DTD that you're required to use, I can't comment on whether it's
reasonable that you have to get back to the chapter level to insert a table, but I
believe that the reason that tables aren't allowed in paragraphs is that it's too
subjective. Two authors might look at the same hard copy - one might decide that the
table belonged inside the paragraph, the other might believe that the table relates
to a number of paragraphs, not just the one that immediately precedes the table. (Of
course, this wasn't an issue on paper - the paragraphs and the table appear linearly
and it's left to the reader to formulate the appropriate associations between the
objects.) The options are to either cater to both scenarios (resulting in a very
sloppy DTD) or take the decision that will hopefully provide the fewest problems,
though some may argue its sanity. Other issues that may have come into play are what
level objects get addressed to - in other words, if you pulled an element out of the
document, would the table and all other relevant elements come with it? Also, what
has been employed by the DoD in other DTDs? The aim is always going to be to keep
the DTDs as close structurally as is possible without shoe-horning authoring.

The point is, you need to juggle a number of snarling cats. You have been provided
with a structure (DTD) and a document and have been told to make the two work as
one. Most likely, nobody has considered whether the current document structure is
conducive to the DTD, someone has been told at the last minute that "as part of the
deliverable...". You need to figure out whether you should change the DTD (almost
certainly not) or change the structure of the Word document (maybe, but without
changing the intent...). "What is the most efficient way to reconcile a linear
paradigm into a recursive structure, and why has this quandry been dumped on me?" is
a realistic question for the embattled writer. This illustrates another facet of the
way that the role of technical writer (or whatever the term du jour) is changing. It
used to be that you might have had to get the document to print in another
application, if in fact the deliverable wasn't just paper. Now you need to be
concerned with how data will ultimately be used and whether the provided storage
model is appropriate.

Technical writers, head for the hills. It's going to get messy.


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