Posted by Frank Ralf on February 27, 2015 at 2:38pm
Last updated by Frank Ralf on Mon, 2015-03-02 17:19
Last updated by Frank Ralf on Mon, 2015-03-02 17:19
Questions and decisions regarding the Drupal implementation of DITA.
- Drupal 7 or 8?
- Only publishing or also creating and managing DITA XML content?
- Source format: DITA XLM or XHTML output of the DITA Open Toolkit?
Comments
Source Format: My opinion
Hi all... Just joined this group. I'm not a Drupal user per se, so take it with a grain of salt. My current DITA project is in an environment that uses two other CMS-like systems, neither of which imports native DITA -- much to my amazement and profound disappointment. (Nor do they make it easy to import XHTML.) Boy, would I like us to use a SINGLE CMS, and would I like it to read DITA!
So it should be no surprise that I advocate native DITA import. The goal from a technical content POV should be to have a canonical source that you can distribute/publish to as many targets as possible, with as little effort possible. To that end, I don't even bother with an HTML transform via the OT -- I ship my DITA with the product and transform it in the browser per topic request. My feeling... The less you touch the DITA, the better.
Being strictly selfish, I would like to merge subsets of my content into a larger CMS publication, with no more effort than identifying what to merge, from where, and to where. Having to generate XHTML and then map that seems more complex to me.
That said, I understand that support for DITA can be huge... Especially supporting specializations. I'm looking forward to Lightweight DITA as a workable subset. Note that the LwD project includes Markdown and HTML5 representations of "DITA" -- meaning DITA is not an XML implementation, rather it's a structure specification.
In my own project I sidestep the complexity by authoring only in topics, and only supporting a subset of that content model. So again, I have a bias. But native DITA is my knee-jerk opinion, for what it's worth.
Hope you don't mind a newbie being a loudmouth so immediately...
Limited tag DITA implementation
DITA can be configured so that there are not so many tags available when you write. I created an authoring version of DITA that is a subset of the out-of-the box DITA model. The authoring DTDs remove mixed content from models like the section element. In plain terms, this means that when you put content into a section you have to open a p element to begin inputting text. But because of this restriction, I was able to remove about 45 percent of elements from the section content model leaving only those elements that an author should be using.
The other thing that the authoring DTD package provides is a central configuration file that allows you to enable or disable any combination of the DITA domains just by changing a single setting for each. These changes then automatically propagate to each of the topic DTDs. For example, you could remove all of the programmer elements, software elements, and user-interface elements from all of the DITA topic DTDs by changing three settings in the configuration file.
The authoring package (com.tagsmiths.authoring.dita1.2) is available for free as a DITA-OT plugin on my GitHub dita-ot page. That page also has a DITA-OT plugin that implements the DITA 1.3 Troubleshooting topic.
Bob Thomas
Tagsmiths, LLC