One of the key questions when considering moving to the DITA authoring standard is: how is it different from what I have today? If you create technical documentation using a Help Authoring Tool, such as Flare or RoboHelp, you’ll probably want to compare DITA to these.
It’s not as easy a question to answer as you might think. As DITA is a standard rather than an authoring tool, you’re actually looking at two different things. However, let’s give it a go.
[table id=1 /]
[table id=2 /]
It’s been pointed out to me that there is a way of having a hierarchical structure inside an individual DITA topic, although you’d be stupid if you did so. The “composite topic” or “ditabase” is a DITA information type that can have topics within topics, and those topics can be arranged into a hierarchy. Ditabase pre-dates the ditamap.
We’ve been asked about DITA and automatically “filling in” default metadata values in a topic. Strictly speaking, it doesn’t (although DITA authoring tools may have this feature), but it offers the same capability. DITA’s <defaultSubject> can be used to define a set of metadata values where none have be specified by the author. For example, you have product attributes: “Basic” and “Professional” for the Basic and Professional versions of your product. If there is a <defaultSubject> value of “Basic”, then the publishing processor will generate content using “Basic” setting for the product (i.e. it will generate a guide for the Basic version) unless the author explicitly has set a value (and no other inheritable value is set anywhere else).
Do you agree?
Do you agree with this summary? Anything we’ve missed? Please add your comments below.