Abstract

FrameMaker overview

Structured and unstructured FrameMaker

Components of a structured FrameMaker solution

Starting points

The FrameMaker document model

FrameMaker customization

Language support

Entities

Building document structures

Resources and references

Starting points

The complexity of the XML-FrameMaker integration depends on your starting point—what format are your current files in and what, if any, requirements have already been defined for the structure? The most common starting points, listed here in order of difficulty, are as follows:

• Unstructured FrameMaker to structured FrameMaker
• Word to structured FrameMaker
• XML-based authoring with FrameMaker as the rendering tool

For a detailed discussion of the high-level implementation process, refer to the Scriptorium Publishing white paper, Managing implementation of structured authoring.

Unstructured FrameMaker to structured FrameMaker

Moving from unstructured FrameMaker to structured FrameMaker requires you to create an EDD that matches the implied structure in your FrameMaker files. See Figure 9, which shows the structure extracted from a lesson plan.

If you have used a formatting template consistently with few or no overrides, conversion of the unstructured files is simplified.

Implementation in FrameMaker requires the following basic steps:

1. Review existing files and extrapolate structure from them.
2. Create an EDD that describes the document structure.
3. Add formatting information to the EDD, either by referencing template components or by embedding formatting in the EDD.
4. Convert unstructured documents to structure.
5. Create scripts to automate cleanup of common conversion problems (deleting extra paragraph tags used as graphic anchors, for example).

Structured FrameMaker is a superset of unstructured FrameMaker, so the document model used in unstructured FrameMaker will map to structured FrameMaker. This simplifies conversion from unstructured FrameMaker. Conversion difficulty is increased by the following factors:

• Formatting overrides and inconsistent/underdeveloped templates. In structured FrameMaker, you must account for all authoring possibilities ahead of time; authors cannot create elements on the fly. It is difficult to convert files to structure when the source files use a poorly implemented template, have significant overrides, or use different (author-created) tags in each file.
• Inconsistent or absent document organization.
• Complex, manual formatting (for example, a single table that’s been modified with custom ruling and shading to look like two tables with a gutter in between them).
• Metadata required in the structured files for which there is no equivalent in the unstructured files. A common example is that generic sections (using a Heading2 tag for the title) become several different types of sections in the structure. It may be impossible to map a single paragraph tag to a Reference, Procedure, or Concept element depending on the type of information in the section.
• Documents with multiple flows. In structured FrameMaker, each flow has its own structure. You cannot associate information in different flows. For example, if you set up an instructor guide with a Student flow and an Instructor flow side by side, the two flows do not have any relationship, except that they are positioned on each page to look related.
• Formatting “cheats” where the document’s visual appearance is different from the underlying components. For example, tables are often used for nontabular data, such as bulleted items in multiple columns or one table with custom ruling and shading to mimic two side-by-side tables. These work-arounds cause problems when you attempt to process the structure later.

If your source files are in unstructured FrameMaker, you need not worry about product-specific issues such as language support (any language you’re using in unstructured FrameMaker is also supported in structured FrameMaker).

Conversion from any unstructured word processor format to a structured environment is challenging, but the close relationship between unstructured and structured FrameMaker make that conversion slightly easier.

Word to structured FrameMaker

Like unstructured FrameMaker, Microsoft Word is a word processor. Converting Word files to structured FrameMaker requires the same basic steps as conversion of unstructured FrameMaker files. There are, however, some additional complications:

• You cannot use a Word template as a basis for formatting in structured FrameMaker, so you need to create a FrameMaker formatting template.
• Conversion from Word into structured FrameMaker is more complex than conversion from unstructured FrameMaker. You can use scripts for pre- or post-processing files during conversion to reduce manual cleanup on the files.
• Word’s table model is quite different from FrameMaker’s. For example, Word permits nested tables and tables that do not follow a regular grid; FrameMaker does not.
• Word macros do not convert into FrameMaker.

Word files with a template and consistent styles are much easier to convert than files that use the Normal style with ad hoc formatting.

Predefined XML structure to structured FrameMaker

If you are required to adapt structured FrameMaker to use an existing XML DTD or schema, you can expect to have significant implementation challenges. Structured FrameMaker, like all publishing tools, has a specific document model. If the document model described in the DTD does not match the FrameMaker document model, you may need to do considerable programming work to make the two models compatible. The FrameMaker document model is described in the section that follows.

Next page:
The FrameMaker document model

Copyright © 2008 Scriptorium Publishing Services, Inc. All rights reserved.