Table of Contents
Advertisement
13
Introduction to Translating between
Markup Data and FrameMaker
FrameMaker can read and write markup data without any help from you. However, its
default translation of markup constructs may not be suitable for your DTD. In such cases,
you have to write a structure application to modify the translation.
In this chapter
This chapter talks about the information your application typically contains. In the outline
below, click a topic to go to its page.
Descriptions of the types of modifications to the default translation that you can make:
•
•
An example to illustrate these points:
•
Discussion of locking XML and FrameMaker files:
•
What you can do with read/write rules
Read/write rules are needed for a variety of reasons. Most rules perform tasks falling in one
of these categories:
Working with special constructs Because markup doesn't standardize a model for
constructs such as tables, graphics, or cross-references, their handling is unique to each
DTD. When creating a DTD from an EDD, FrameMaker makes assumptions about how to
translate these FrameMaker constructs to markup elements and attributes. Your application
may need only to modify the default translation in minor ways using rules. On the other
hand, when creating an EDD from a DTD, FrameMaker cannot recognize these constructs,
so your rules need to be more extensive.
Renaming elements and attributes FrameMaker element tags and attribute names are
frequently more descriptive than their XML or SGML counterparts and you might use a read/
write rule to establish a correspondence between names. For example, you could use a rule
to change the FrameMaker tag Employee Name to the XML generic identifier ename.
Structure Application Developer's Guide
"What you can do with read/write rules," next
"What you can do with structure API clients" on page 202
"A detailed example" on page 203
"Opening XML documents" on page 207
13
201
Advertisement
Table of Contents
