Sam, It sounds like you're using unstructured FM? We are, and we considered going to Structured FM, but the learning curve and conversion time just wouldn't fit into our very tight (R&D) timelines. (I still fantasize about it, though! LOL)
We have the same setup here with our product life cycle control system. We have to provide the source files for each document for each product, even though they're single-sourced. It has taken a couple of years of trial and error and gleaning new ideas and tools from contributors to this list for us to piece together a process that works well for us, and it's not a single answer. I'm sure you'll figure out the right solution for your environment. We have found that due to the quirks of how FM handles headings and conditional text in text insets, it is only easily manageable for us to use text insets in body paragraph chunks that do not contain condition tags or variables. In this case, the text inset itself is literally the smallest discrete chunk?i.e., a single procedure that is reused multiple times in one or more books, a product overview paragraph, some standard warning text, a common note, etc. If the text inset doesn't apply to all outputs, we conditionalize the insertion marker itself for the text inset so that the whole inset shows only in the tagged output. We do use some shared files that are heavily condition tagged and included in several book files for output purposes. In a boilerplate folder, we have the boilerplate stuff from the copyright notice, the Preface, and the universal glossary set up as separate FM files in a common files directory on the network. Each of these files is tagged to show only what is appropriate for each output that uses them. The benefit of having a universal glossary this way is that all writers can contribute to it; it's all synchronized after a single edit; and everyone can link into it via cross-reference or hypertext links without losing anything when they update the book. Likewise, updates to release statements, copyright dates, trademark notices, etc., are all handled in a single change that ripples through the entire library. We have variables in the headers and footers of all master pages of all FM files (template-based) wherever the doc number, doc title, issue date, etc., are needed. This facilitates quick customization. We use conditioned anchored frames on the cover as well as the variables to customize what shows for each product line. We have a folder for common product files where we keep things like the appendices of part numbers, ordering information, etc. All of these files are heavily condition tagged?down to the word or table row or cell text level. For each output, there is an individual book file with coordinating [outputName]settings.fm file. The setting file contains only the 5 user variables required for changing the doc title, doc number, issue date, release number, etc., as well as the condition tag settings required for publishing that particular output. The book file contains all the files required for the output: * Cover * boilerplate front matter * TOC * LOT * LOF * Chapter files (som shared, esp. between install, maintenance, and troubleshooting docs) * Appendices (often shared) * boilerplate backmatter * IX At publication time, we open the book to be published and its settings.fm file; update the variable definitions as needed in the settings file; and then use Rick Quatro's ImportFormatsSpecial plugin to apply just the condition tags, PDF settings, and user variables to the book's files, before generating the appropriate PDF or online output. (NOTE: If you have ePub, you can use "stationery" to set this up for you automagically as part of the sequence of output creation.) As soon as the output is generated, we use Bruce Foster's Archive plugin to create a discreet, reproducible project folder that we archive as a zip file in our CMS. (There are ways to use this same plugin in conjuction with ClearCase or other CMS for individual file check-in/check-out?frequently discussed on this list?but we've chosen to keep the source encrypted as part of doc security and check in/out as a single file for streamlining purposes. And, there are several other plugins and FrameScripts that we have bought and use frequently, but these two are the ones that are part of our final production process.) For product-level content management, there is a single book file for each product that incorporates all the chapter files, text insets, and shared product-level files, so when we need to run spellcheck or apply new template updates, we can do so efficiently and effectively. This said, it is for us an efficient model, but it's a level of complexity that writers new to our shop find challenging to get into the swing of things. Those of us who have been here as it has evolved are like the proverbial frogs in boiling water: we don't notice the heat, because it was increased incrementally. ;-) HTH Rene Stephenson Ellen Lebelle <elebelle at gmail.com> wrote: << If these documents were for a new product line, we MIGHT be able to get away with putting them into a single number. However, they are for two separate but similar product lines. The first one is 1950 while the second one is 2158. OK, Sam. How about using smaller text insets that you import into your chapters. So your chapter is a shell - not quite empty - you can have most of your generic text there, but when you get to a topic that is product A, you import the text inset for product A and make it "conditional" and do the same for product B. When you import your conditional settings from the book cover, only the relevant text insets will appear. Use Bruce Foster's Archiver to make an archive of the A book and label it with the date and number. Do the same for Book B and these archives remain archives, and your source files can be updated without fouling up the archived books.
