Adobe 65030365 - FrameMaker - PC Developer's Manual page 543

H
I m p l e m e n t i n g a n X M L o r S G M L a p p l i c a t i o n i n t h e
F r a m e M a k e r p u b l i s h i n g e n v i r o n m e n t
Adobe FrameMaker Application Development
Developing a FrameMaker application shares many steps with developing a markup
application for any other editing or publishing tool. This section summarizes the process,
covering the steps common to other editing and publishing tools, and those unique to
FrameMaker. Itemization of the various steps is preceded by a brief description of the
approach to document processing that FrameMaker uses.
FrameMaker Editing Philosophy As the preceding formatted taskmodule example
illustrates, visual clues—font variation, indentation, and numbering—help readers
understand and use written information. FrameMaker is a WYSIWYG editor. While most
WYSIWYG editors require authors to indicate how each part of the document is formatted,
FrameMaker uses the rules in the markup application to format document components
automatically in a consistent manner.
This combination of WYSIWYG techniques with the structured principles of markup is
unique to FrameMaker. The goal in FrameMaker, is to streamline the process of creating
and publishing documents through the use of markup. While authors manipulate elements
and their attributes to create native markup documents, they work in a WYSIWYG fashion
instead of directly with markup syntax.
Since the markup document model underlies edited material, the markup form of the
document can be produced at any time during the WYSIWYG editing process. This process
relies on the underlying element structure and hence has no need for the inaccurate filtering
schemes that plague tools for generating markup from word processing formats.
Tasks in FrameMaker application development The major tasks involved in the
development of a FrameMaker application are:
•
Defining the elements that can be used in a document and the contexts in which each
is permitted. This task is analogous to developing a DTD. In fact, the element definitions
can be automatically derived from a DTD if one exists.
•
Determining which elements correspond to special objects, such as tables, graphics, and
cross-references.
• Developing format rules that define the appearance of a structural element in a particular
context.
•
Providing page-layout information such as running footers and headers, margins, and so
on—the foundation of every WYSIWYG document.
• Establishing a correspondence between the markup and FrameMaker representations of
a document. For most elements, this correspondence is straightforward and automatic,
but FrameMaker allows for some variations. For example, terse markup names can be
mapped into longer, more descriptive FrameMaker names, and variant representations
of tables, graphics, and other entities can be chosen.
Each of these tasks requires planning and design before implementation, as well as testing
afterward. The rest of this paper describes these steps, and the skills needed to perform
them, in more detail.
Structure Application Developer's Guide 525