What is wrong with the table structure?

Ahsan,

   Thank you for explaining your workflow. To continue, I assume that once you have exported element definitions to create an initial EDD from the result of structuring an unstructured document, you update that initial EDD and do not create a new EDD each time you structure a document. The type of changes you can make include:

1. Modifying general rules.
2. Adding format rules to indicate paragraph, character, table formats, or object styles to apply to the various elements. You can apply individual paragraph and character properties as well as applying entire formats from the appropriate catalog.
3. Rearranging the element definitions, possibly dividing them into sections, and grouping related elements together.
4. Adding Paras between element definitions and Comments within them to document their purpose and explain the specifications you have made.

  Once you are satisfied with the result of one document, you can convert another unstructured document with the same conversion table. If the second document uses more element types than the first one did, you can add more rows to the conversion table. You can add the additional rows manually or by using the Update Conversion Table option from the Generate Conversion Table command. As you work on the second document, you can add any new element definitions (or format rules) to the existing EDD. You do not necessarily need to create a new EDD by exporting element definitions from the second structured document. If you do, though, manually copy the relevant changes into your base EDD.

   At some point you will also develop a structured template which includes the paragraph, character, and table formats and master pages that form the basis of formatting your structured documents.

   As your structured environment matures, you may be able to stop using the conversion table and creating unstructured documents, creating new structured documents directly from your structured templates. If you have a base of unstructured documents that you want to move into a structured environment, or if you want to convert documents created from a tool other than FrameMaker (for example, from Microsoft Word), then you will continue to use conversion tables). Your mature environment also depends on whether you have an XML requirement, either for using FrameMaker to format existing XML documents, or saving completed structured documents as XML.

   As far as how to understand the relationships between elements, conversion tables, and EDDs, much of that depends on your background. Have you used XML? Are you familiar with regular expressions? How familiar are you with unstructured FrameMaker documents? If you are completely new to structured documentation and have never used such tools outside of FrameMaker, in an ideal world you would start by editing structured documents that use element definitions that someone else has established. Once you are comfortable with the motivation and concepts of structure, you can move on to working with an EDD, and then learn about conversion tables.

  How big is your organization? Are there other writers in the publication team? Typically, a writing group has a small team (possibly only one person) setting up tools such as FrameMaker for a larger group of writers, editors, and production staff.

  If you are working by yourself, the most obvious ways to learn are through forums like this one and the FrameMaker documentation. EDDs and conversion tables are documented in developer manuals rather than the basic user manual. Depending on various considerations (such as budget) you may want to take some training courses or work with one of the many consultants (including myself) on this list. Consulting services can range from creating your EDD, template, and conversion table to answering questions about those you create.

      --Lynne