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
_______________________________________________
You are currently subscribed to Framers as [EMAIL PROTECTED]
Send list messages to [EMAIL PROTECTED]
To unsubscribe send a blank email to
[EMAIL PROTECTED]
or visit
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com
Send administrative questions to [EMAIL PROTECTED] Visit
http://www.frameusers.com/ for more resources and info.
