<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN'>
<html><head><meta http-equiv="Content-Type" content="text/html;charset=us-ascii">
<style>BODY{font:10pt Tahoma,Verdana,sans-serif} .MsoNormal{line-height:120%;margin:0}</style></head><body>
Hi Rebecca<br><br>While reading your post I was thinking, "XML" - and then you asked the question right at the end.<br><br>You don't say which wiki the engineers are using; that would be an important factor.<br><br>Some of what you are looking for can be done using FrameMaker and DITA. The engineers would soon learn the DTD (I'm told that engineers like learning stuff like that). You and your writers would have a significant learning curve too, and it would take several months to implement.<br><br>There is a plugin for Confluence wiki (DITA2Confluence) that will publish a ditamap and all its referenced content to wiki pages. But it is only a one-way transfer; you can't capture changes made on the wiki back to your FrameMaker source. And in the meantime Confluence 4 has switched from using wiki markup to using XHTML, so the plugin may not work with the current version of Confluence. (I'm sure there is work going on to remedy that.). The pathway from FrameMaker to wiki is not too difficult; it is the other direction (your engineer source) that will be the problem.<br><br>In your situation I would be looking at more radical solutions. What about publishing your user manual through the wiki? Most wikis can output PDF too, though it will not be as pretty as that provided by FrameMaker. Instead of sticking with FrameMaker, I'd be thinking in terms of a text-based source (XHTML or XML), and tools that can convert from wiki to XML. One such is the Mylyn Project at <a href="http://www.eclipse.org/mylyn/">http://www.eclipse.org/mylyn</a>. See<a href="http://greensopinion.blogspot.com/2008/11/mylyn-wikitext-targets-oasis-dita.html">http://greensopinion.blogspot.com/2008/11/mylyn-wikitext-targets-oasis-dita.html</a>.<br><br>Of course, if the XML ends up being DITA or DocBook, you can publish that through FrameMaker (or lots of other tools).<br><br>I hope other list members will be able to add to these thoughts... You could also try asking the question on the Yahoo dita-users group at http://tech.groups.yahoo.com/group/dita-users/. There are people there with all kinds of experience, and I'm sure someone will have some suggestions.<br><br>Roger<br><br>Roger Shuttleworth<br>Technical Documentation<br>AV-BASE Systems Inc.<br>1000 Air Ontario Drive, Suite 200<br>London, Ontario<br>N5V 3S4<br>Tel. 519 691-0919 ext. 330<br><blockquote style="padding-left: 5px; margin-left: 5px; border-left: #0000ff 2px solid; margin-right: 0px"><hr><b>From:</b> rebecca officer [mailto:rebecca.officer@alliedtelesis.co.nz]<br><b>To:</b> framers@lists.frameusers.com<br><b>Sent:</b> Mon, 25 Jun 2012 02:02:53 -0400<br><b>Subject:</b> Single sourcing from Frame and a wiki ... or something ...<br><br>
<div>Hi everyone</div>
<div> </div>
<div>Our docs team (4 of us) creates a many-thousand-page multi-chapter user manual in unstructured Frame. Lots of tables and cross-refs. Conditional text used to publish several variants. Published as PDFs a couple of times a year, delivered online. </div>
<div> </div>
<div>And the engineers (about 80) have a wiki that's a mish-mash of internal feature development info, some of which ends up in the user manual.</div>
<div> </div>
<div>I've been asked to make the user manual and the internal docs use the same source, which both writers and engineers would write. We want to work collaboratively, stop duplicating effort and come much closer to real-time updates.</div>
<div> </div>
<div>I'll need to include version control, content re-use, status tagging (e.g. draft/final), read-only access, and delivery as PDF and HTML. While I'm at it, I'd like to do automated builds and publish ebooks.</div>
<div> </div>
<div>The engineers would like the wiki to be the source. The writers want to stay with FM. I'm prepared to make everyone change tools (*grin*) but only if we have to.</div>
<div> </div>
<div>As a complicating factor, the engineers are all on Linux. Getting an FM licence per engineer would blow my budget (Adobe, how about selling a site licence???), and they'd have to run it in Virtual Box. I'm not seeing a happy ending there.</div>
<div> </div>
<div>I've got plenty of implementation time and can lay my mitts on a programmer or two. Budget's not yet set but prob around $20K.</div>
<div> </div>
<div>So ...</div>
<div> </div>
<div>Does anyone know of a good tool for round-tripping Framemaker <--> Wiki? </div>
<div> </div>
<div>Should I be looking at XML?</div>
<div> </div>
<div>Any other thoughts on how I should tackle this?</div>
<div> </div>
<div>Many thanks<br>Rebecca</div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<br>NOTICE: This message contains privileged and
confidential<br>information intended only for the use of the addressee<br>named
above. If you are not the intended recipient of<br>this message you are hereby
notified that you must not<br>disseminate, copy or take any action in reliance
on it.<br>If you have received this message in error please<br>notify Allied
Telesis Labs Ltd immediately.<br>Any views expressed in this message are
those of the<br>individual sender, except where the sender has the<br>authority
to issue and specifically states them to<br>be the views of Allied Telesis
Labs.
</blockquote><style>
* {MARGIN:4px 4px 1px;FONT:10pt Tahoma;}
</style>
</body></html>