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
_______________________________________________
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.
