How do you store your information?

[Marcus Carr]

Gordon McLean wrote:

> We use structured FrameMaker. We have a mature EDD, we are happy with the
> way things are.

Good. That's one aspect that you shouldn't need to change then.

> But it's not really any closer to single source, or modular documentation,
> as we still have the content stored in .FM files and organised in books.
> However, trying to find out the best way to store the documentation, so it
> will be properly modular, is proving tricky (of course, it may just be my
> interpretation and understanding that is lacking).
>  
> Does anyone store their content in a database? Or as XML? How re-usable is
> your solution?
>  
> We have a lot of similar areas of our product, and I want to make the best
> use of the existing content but at present it's still a lot of cut-n-paste
> which is not good. 
>  
> Where am I going wrong?

In my opinion, you're going wrong by looking for FrameMaker to act as a 
content management system, not a typesetting engine. You're also 
thinking of the information in terms of end product instead of data 
fragments, as evidenced by the fact that you have .FM files organised in 
books.

If it was my data, I'd first figure out the appropriate level of 
granularity for the purpose of editing, cut up my data and save all 
unique fragments as individual XML files. Then I'd figure out which 
combination of files was required for each given publication. Then I'd 
get a programmer to write something that built a consolidated document 
for the purpose of publishing. I'd open that in FrameMaker and produce 
my PDF (or whatever), treating FrameMaker as a superior typesetting 
engine that accepts XML data. (That is FrameMaker's best side, in my 
opinion.)

Do you need a database? Maybe but not necessarily - it depends on the 
size and complexity of your dataset. Could you accomplish the same thing 
from within FrameMaker? Probably, but your dataset will be owned by 
FrameMaker as migration to another application would be difficult, 
contrary to the benefits one typically ascribes to XML. Do you need 
DITA? No. Given that you have an EDD that you're happy with and a 
dataset big enough to be troublesome, I don't see why you should change 
your structure. Do you need a "product" to accomplish all of this? Not 
as long as you understand the problem that you're trying to solve. Is 
this stuff easy? No, but if you solve it properly once, it will be easy 
to maintain.

Agile data in a more complex system is worth much more than locked down 
data in a simple system.


Marcus