Gordon McLean wrote: > As you rightly point out, FM is not a content management product. I > am fully aware of that fact, but unfortunately it seems my > predecessors either weren't, or (as is more likely) hadn't managed to > take the next step forward towards 'better' single sourcing. I'm > eternally grateful that I inherited a well formed EDD though!
Everyone is aware of it, but workarounds exist that make it enticing to try to manage data in FrameMaker, so I'm never surprised that anyone takes that path. This list regularly contains clever ideas for managing data fragments, but ultimately those approaches probably don't scale as well as a more abstracted approach. A good EDD gets you a long way forward though. > As for breaking up the files into XML chunks, I have the level of > granularity pretty much sorted, content and re-use maps in place, and > the only thing that is stopping me hacking it all up is covered by > this sentence of yours: > > "Then I'd get a programmer to write something that built a > consolidated document for the purpose of publishing." > > When you say "consolidated document" I'm presuming that that is an > XML file that, more or less, equates to a chapter (for example)? I'm > also presuming that, once such a document is in place, I can use FM > to handle book files (which don't contain any content), and generated > lists (TOC, IX etc) as per usual. Yes, it would be XML and it may well be a chapter. The issue is that you have the requirement for two levels of granularity - one for maintaining and reusing data and another for publishing it. All of your TOCs and generated lists would be done as usual. There would still be issues to consider - for instance, if you use change bars you may need to come up with a different approach. Indexes may also be a bit more difficult, as it's hard to index fragments independent of their final configuration, and I'm sure you'd stumble into other small issues, but on the whole, it shouldn't hurt too much. > We have SVN in place here, so storing and maintaining the XML files > isn't too much of a hassle (it's just a glorified file system, > innit!). So I guess I "just" need to crack that middle stage. The > techie in me, naturally, baulks at the idea of asking a programmer > for help.. ;-) Creating a consolidated XML file likely wouldn't be difficult - if you strip off the XML declarations from the fragments and dump the contents into some sort of container element, you'd probably be most of the way there. The programmer needn't remain involved - all you need is the code and the means to run it. It could probably be a simple Ant script or a batch file that grabs the usage map for a publication and outputs the chapter files. > Thanks for the clarification. I think I had the basic ideas in my > head but without hearing this I was fearly of venturing off down a > darkened path. It's not that dark once your eyes adjust, and you're right in the centre of the path. None of this stuff involves any big buy-in or irreversible action, so I'd prototype the whole process from start to finish if I was you. You might find that it's all a lot less complicated than you had anticipated. Feel free to contact me off-list if you're getting stuck on the details. Good luck! Marcus
