One such method is provided in the element catalog of EDDs themselves. Format change lists allow an EDD developer to define information once and use it repeatedly throughout an EDD. However, format change lists are limited in their possible structure. As the term implies, they contain lists of formatting properties, but cannot contain other structures (for example, complete formatting rules) that a developer may want to repeat.
Since an EDD is a structured document, any technique for reusing part of a structured document can be applied to an EDD. In particular, variables, conditional text, and text insets may allow a developer to share EDD fragments across a set of related EDDs as well as defining something once and using it many times within on EDD.
FrameMaker user variables can be defined for strings that
are used repeatedly in an EDD (for example, the amount of
extra indentation in a list). To indicate where variables
are used, the developer may wish to define a character format
for them. For instance, a character format called
Variable
might set all properties except color to As Is
and set color
to Red
. A variable called ListIndent
might
be defined to be
<Variable>24pt
. Uses of ListIndent
would then appear in red in the EDD and hence be distinguished from
surrounding text.
Furthermore, alternate sets of variable definitions can be maintained in different FrameMaker documents and imported into an EDD as needed. For example, suppose an organization produces documents in two languages, say, English and French. EDDs for the two languages may differ only in the text included in prefixes for some elements. The prefix text can be defined in variables. In addition to the EDD, the developer can maintain two other FrameMaker documents. No text is needed in either, but both should define all the variables used in the prefixes. One file should define the English versions of the prefixes and the other the French versions. To update the English template, then, the developer first imports variable definitions from one of these files into the EDD and then imports element definitions from the EDD into the English template. Analogous steps are made for French. The advantage of this approach is that any EDD changes that do not involve prefixes need be made in only one EDD and not duplicated in separate English and French versions.
Although variables cannot contain elements and are limited in length to 255 characters, text insets allow long and structured segments of an EDD to be defined once and used multiple times. FrameMaker 7.0 supports three types of structured text insets:
Of course, the use of SGML or XML text insets requires a structured application for representing the EDD in the markup language. Since an EDD is a structured document such an application can be built. Text structure Consulting, Inc., offers such an application for its metatemplate.
If nested text insets are used, the DTD for a structured application for EDDs must change with each EDD processed. A nested text inset is included in a markup language text inset via an entity reference. The application's DTD must declare the entity. The DTD can be organized in several files, with all entity declarations for text insets in one file. Thus, to use the application for a new EDD, therefore, is a simple matter of editing the file with the entity declarations for text insets.
Without FDK support, there is another problem with FrameMaker and XML text insets (but
not SGML text insets). It is often useful for a text inset to consist
of a sequence of adjacent siblings but not their
common parent. For example, suppose that two common
attributes are defined for numerous element types, but that some of
the element types have additional attributes as well. A text inset
that contained the definition of the common attributes could appear
within the attribute definition list for all relevant attribute
types. Since the AttributeList
element does not appear
in the imported file, other attributes can be defined as well.
It should be possible to import FrameMaker flows containing multiple
siblings. While the imported flow must have a single highest-level element,
FrameMaker unwraps a root element named SGMLFragment
.
Unfortunately, FrameMaker (through version 7.0) sometimes crashes or
produces incorrect
results when unwrapping a highest-level SGMLFragment
with more than one child.
A similar problem occurs with XML text insets. FrameMaker 7.0 cannot add an XML text inset to an existing document unless the text inset consists of a single subtree. (When importing an entire document from XML, it can create XML text insets consisting of multiple adjacent siblings).