Documenting EDD formatting

[DW Emory <danemory@xxxxxxxxxxxxxxxxxx>]

EDD developers have an obligation to fully document all paragraph, 
character table, and cross-reference tags which are created when an EDD is 
imported into a document whose purpose is to function as a structured 
document template. Such documentation is essential in order for template 
designers to customize structured templates for use with different types of 
document deliverables and/or different customers.

In most cases, paragraph tags specified in the EDD should include the 
CellHeading, CellFooting, and CellBody tags for tables, the Footnote and 
TableFootnote tags, the Body tag for ordinary body text, tag(s) for various 
types of headings and titles, and miscellaneous special-purpose tags (e.g., 
anchor paragraphs for tables and graphics, empty delimiter paragraphs, etc.).

Ideally, the design documentation provided by the EDD developer should:

1. Identify the tagnames of all EDD-specified tags, and provide a list of 
the elements in which each tag is specified to be the element paragraph 
format, the initial table format, the character format, or the initial 
cross-reference format. The template designer must have this information 
not only because those tagnames may not be changed, but also because this 
information is essential in order for the template designer to develop a 
plan for successfully making required format modifications to those tags.

2. For each EDD-specified paragraph tag, identify those formatting 
parameters (e.g., font family, font size, line spacing, language, pair 
kern, widow/orphan lines, hyphenation, word spacing, automatic letter 
spacing, table cell margins) which are never modified by EDD format rules 
in any context in which that paragraph tag is used. This information is 
essential in order for template designers to know which paragraph 
formatting parameters are modifiable in all contexts where that tag is 
used. For example, the Body paragraph tag is typically modified by format 
rules in many different contexts, and retains its default (i.e., 
unmodified) format settings only in the case of ordinary unindented and 
unadorned body text.

3. If an element paragraph format tag is not specified in the EDD for a 
container element (in which case different paragraph format tags may be 
inherited from different antecedents in different contexts), this fact must 
be fully documented in order for the template designer to understand that 
the formatting of such text elements cannot be successfully modified by 
modifying a single paragraph format (as would be the case if an element 
paragraph tag were specified).

4. For EDD-specified character tags, the explicit purpose of each such tag 
should be described. As a general rule, EDD-specified character tags should 
not specify a font family, and EDD format rules ought not to be used to 
modify such character formats in different contexts. Exceptions to this 
general rule must be documented so that the template designer fully 
understands the limits within which changes in EDD-specified character 
formats can be successfully implemented.

Clearly, an EDD implementation in which all (or at least most) 
context-based EDD format rules specify format change lists (all of which 
are typically located at the end of the EDD) is the optimal approach. This 
allows a single format change list to be referenced from many different 
format rules, and also permits using format change lists as building blocks 
by combining several of them in to define a particular format in a 
particular context. By placing all of the format change lists at the end of 
the EDD, you can create multiple versions of a single EDD simply by 
modifying the format change lists, leaving everything else unchanged.

FrameMaker/FrameMaker+SGML Document Design & Database Publishing
DW Emory <danemory@globalcrossing.net>


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