[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[New search]
To: edunn@xxxxxxxxxxxxxxxxxxxxxxxx, Framers@xxxxxxxxxxxxxx, Framers@xxxxxxxxx
Subject: EDD Maintenance Techniques (Re: Frame+SGML: Prefix Rules and Attributes)
From: "Lynne A. Price" <lprice@xxxxxxxxxxxx>
Date: Tue, 12 Jun 2001 23:16:03 -0700
In-Reply-To: <85256A68.0048A8C4.00@btg_hub01.bombardier.com>
Sender: owner-framers@xxxxxxxxx
Eric, Since we're discussing EDD maintenance techniques, you might find the following comments useful. When I use variables in an EDD (or in an SGML application file), I usually use a character format to distinguish them from surrounding text. For example, I've been working on one project in which the same EDD is used sometimes for technical documentation and sometimes for training material. The primary division of a book is called Chapter in technical documentation and Module in training material, so I use a variable named Chapter that is defined to be <Variable>Chapter when I'm working with technical documentation. When I'm working with training material, I import variable definitions from another file into the EDD. The second file defines the Chapter variable to be <Variable>Module In the EDD character format Variable is defined to set the color to red. I also use numerous text insets. I use conditional text to make the text insets visible by defining a condition with condition indicators to set the desired appearance. I then do a global Find/Change searching for text insets and changing by pasting to apply the condition. I never hide this condition; I use it only for formatting. In this way, without using format overrides, I have a visual clue about which parts of my EDD are text insets. In my metatemplate (template for EDDs), instead of making Element valid at the highest level, I define a new element called SGMLFragment. I define SGMLFragment with the general rule <ANY> and define it to be valid at the highest level. FM+SGML treats the element tag SGMLFragment differently than other element tags. In particular, elements with this tag are unwrapped when they are the highest level element in a text inset. Thus, an SGMLFragment can consist of a sequence of attribute definitions or several format rules. If an attribute is used by several element types, I can define it in an SGMLFragment and include that fragment as a text inset in multiple element definitions. I can then change the default value or make the attribute hidden for all element types just be editing the fragment in one place. Because SGMLFragment is unwrapped, an element definition can include both attribute definitions from text insets and those entered directly. If I'm working on one EDD, I often define the SGMLFragments in reference flows in the EDD, so the entire structure is maintained in one file. Of course, if several EDDs share the same text insets, I put them in a separate file. You mentioned modifying the metatemplate to support multiple highest-level elements. You can also define additional documentation elements (e.g., notes, tables, and lists as well as Paras) and change the formatting. Feel free to look at the metatemplate I use. It's at http://www.txstruct.com/MetaTemplate (case is significant). This directory contains the files: 1) edd.tpl--the FM+SGML 5.5.6 metatemplate 2) edd6.tpl--the FM+SGML 6.0 metatemplate 3) test.edd--a sample EDD using the metatemplate 4) MetaEDD.edd--the EDD for the metatemplate 5) MetaTemplate.zip--a zip file containing the other 4 files MetaEDD.edd has comments that enumerate the various changes I've made to Adobe's original metatemplate. --Lynne At 09:13 AM 6/11/01 -0400, edunn@transport.bombardier.com wrote: > > >That's the conclusion that others have told me. Hadn't thought of using >variables in the EDD yet. Although I do use conditional text quite liberally. >I have also modified the EDD's EDD (that is the EDD that controls the display of >the EDD) to allow Element as highest element. It is then possible to "extract" >an element and then import it as a text inset. This is handy because you can >easily go back to the previous version, plus it is simpler to work with only the >one element at a time. > Lynne A. Price Text Structure Consulting, Inc. lprice@txstruct.com http://www.txstruct.com ** To unsubscribe, send a message to majordomo@omsys.com ** ** with "unsubscribe framers" (no quotes) in the body. **