How do you store your information?

[Marcus Carr]

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