TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:RE: DITA: going from FrameMaker to oXygen From:Chris Despopoulos <despopoulos_chriss -at- yahoo -dot- com> To:<techwr-l -at- lists -dot- techwr-l -dot- com> Date:Thu, 13 Dec 2018 10:54:53 +0000 (UTC)
DAVID SAYS...
 I've been disappointed for years by the use of EDDs and non-DITA XML in
 the tech stack of FrameMaker.
 I'm certainly going to burn a bridge on this post; but why invest
 development time and expect user admins to massage a production
 pipeline, when Adobe money could have fixed the OT, and their tool
 developers could have put Oxygen on alert? Is Adobe so committed to
 their sandbox that they have to 'win' on proprietary features instead
 of crushing on quality applications?
====================
The EDD is a way to map DITA or any other XML spec to FrameMaker formatting. If you want formatted output, you must map XML to that formatting in one way or another. So on principle the EDD is no better or worse than XSL-FO, CSS, or any other mapping mechanism. There are ways in which the EDD is clumsy or difficult to set up. But the resulting PDF that you can get is the best PDF you can get from any tool chain that renders XML in print. Period. (InDesign and Quark might be in the same league, but you can bet they have something similar.)Â
I'm not sure what you are on about with non-DITA XML. So Adobe should abandon DocBook? And any other standard out there? And they should not support authoring in a custom XML implementation? I don't think any serious XML editor would go that route.
Adobe money should not, and cannot fix the OT. The OT is open source. Maybe Adobe should send Jarno a check once in a while for all the work he has put into the OT, but that's another question. FrameMaker does indeed support the OT, and you can send your output to it whenever you want.Â
Could Adobe put oXygen on alert? I think so. Major improvements to the management of their structure applications in a project framework would go a long way. (Again, I haven't explored how far they've taken this tack in the latest release. But I don't hear anybody crowing about it as an oXygen killer.) And cleaning up their "effect" on the underlying XML source when you save might be nice. They could also win points by simplifying their EDD/Template implementations for DITA... The template set they had (until recently at least) is implemented in a way that uses EDD relative formatting way too much IMO. Maybe they need a few implementations, and let people choose the ones they want. Some way to make it easier to customize the templates. Again, maybe they have addressed these issues in the latest release...Â
I guess the thing FrameMaker will never beat oXygen on is their handling of XML as code. oXygen is built on a coding development environment, and they have invested major intellect into the ins and outs of handling XML. But interestingly, your critique doesn't touch on that.
So David I'm sorry, but I think you are not making a fair assessment. You can burn the bridge to FrameMaker, but you'll find lots of the same problems on any of the remaining bridges.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | https://techwhirl.com
