DITA: Technology Strengths and Weaknesses
Opinions about the relative strength or weakness of DITA-aware technologies are plentiful and divergent – to the point suggesting that the people offering opinions are reacting to different things that just happen to share the name “DITA.”
This paper argues that divergent assumptions about what is “real DITA” track predictably to divergent conclusions about relative strengths or weaknesses of its supporting technology. The following breakdown by assumption is an oversimplification, but manages to get at the underlying sources of the divergent opinions.
If someone assumes that DITA is . . . / They typically expect its technology to be . . .Just another “tool” . . .
a.k.a Tool-DITA / Modeled after stand-alone applications such as Adobe FrameMaker, Microsoft Word, or Adobe RoboHelp. Users in this category expect “Tool-DITA” to have the following characteristics:
- An easy-to-learn and easy-to-use graphical interface with access to
to all product features
- Uncomplicated content models – basically simple documents
- Fully productized documentation, installation, and configuration
(shrink-warp)
- Customization (over extensibility)
- Desktop deployments (over cloud- or server-based)
An end-to-end “solution” for every publishing requirement . . .
a.k.a. Solution-DITA / Modeled after MadCap Flare, Author*It, or turn-key document management systems. Users in this category expect “Solution-DITA” to have the following characteristics:
- Proprietary interfaces, services, and enhancements to XML
grammar OK
- Transparent boundaries between tools (editor, repo browser,
publication manager, processing framework(s), and
workflow managers).
- Inner workings not documented
- Extensibility achieved via proprietary “packages” or
“plug-ins” and not via extending or customizing the
base environment.
-
-
A standards-driven framework for developing multiple publishing workflows . . .
a.k.a. Framework-DITA / Modeled after Eclipse-based or OASIS DocBook-based implementations assembled from layered services and open interfaces. Users in this category expect “Framework-DITA” to have the following characteristics:
- Robust, well-documented components and services
- Standards-driven interfaces shared across components and services
- Optimized for extensibility
-
-
Before we dive into the feedback about the strengths and weaknesses associated with each category of DITA user, let’s pause to focus on a few of the indisputable facts.
OASIS DITA (Darwin Information Typing Architecture)
Strictly speaking, OASIS DITA consists of a formal XML language specification written for tools implementers and a set of ready-to-implement-and-customize XML grammars. It is an industry standard developed and maintained by a standards body, OASIS (the Organization for the Advancement of Structure Information Systems). XML editors, XML processing frameworks, component content management systems, and support tools are not DITA, but implementations of the DITA standard for specific purposes and audiences. No commercial product or open-source tool is a definitive or complete implementation of the OASIS standard. OASIS provides no reference implementations or compliance test suites, so DITA implementations with specific tools can vary greatly.
Fundamentally, OASIS is not in the tools business. It has no marketing department promoting DITA as a product or brand, suing competitors that make false claims, or protecting the “boundaries” of the standard. If I were to advertise in technical magazines that using DITA causes skin rashes or promotes alcoholism, I may be reviled in one or two technical blogs, but I will never be sued by OASIS or challenged to submit my test findings to some objective third-party think tank for review. Unreasonable or inaccurate criticisms of DITA and its associated technologies can linger unchallenged in the market for considerable periods of time. Relative to the way for-profit companies develop, market, and defend their assets against unreasonable or unsubstantiated feedback, DITA is at a disadvantage – borderline defenseless. It is a standard competing with product development organizations.
Perceptions Within the “Tool-DITA” Category
Individuals and organizations deciding to move to DITA from a “tool” such as FrameMaker or Word tend to bring their expectations for slick, productized desktop applications with them. They deploy DITA-compliant editors and become frustrated when they cannot easily develop presentation style sheets or tweak page templates. Or - they install a DITA processing framework such as the DITA Open Toolkit and wonder when its GUI interface, XML editor, or content manager will be available.
Two misunderstandings in this area generate most of the perceptions of “weaknesses” in the “Tool-DITA” space.
- There can be only one: Folks looking for one, shrink-wrapped, DITA-compliant application that will do it all will not, logically, ever find it. If there were some compelling business case for developing such a super-app for DITA, one might ask why no enterprising company has not developed it. Potential DITA practitioners need to be educated about the benefits of component-based and standards-based design.
- OASIS owns or directs the development of DITA-compliant tools: The perception that OASIS DITA owns, maintains, sponsors, or promotes particular editors or particular processing frameworks is pervasive and incorrect. The DITA Open Toolkit receives unfair scrutiny as some bellwether “suite” for all things DITA. Again, it is unrealistic to expect any one DITA-compliant component to satisfy all requirements – editing, processing, or content management.
Fundamentally, the criticisms about the lack of a “one-tool-does-all” solution for DITA belie a lack of experience with current development architectures and methodology. The synergy to be achieved by orchestrating a collection of well-designed components or services far outweighs the benefits of forcing everyone to use one IDE or development framework that claims to do everything. Technical publications groups that seek to live in the walled garden of “one-tool-can-do-it-all” do not have a viable future in contemporary engineering organizations. Their reservations about not being able to purchase a shrink-wrap DITA uber-tool are the least of their problems.
Perceptions Within the “Solution-DITA” Category
Another set of assumptions that people can bring to evaluating DITA involves the notion of a “solution.” In Marketing 101 we learn that a “solution” represents a collection of components and services configured to address a specific task or environment. For example, a distributed object-oriented database is a “framework” for developing multiple “solutions” such as an inventory management system or point-of-sales application. In our field of information management and publishing, you can purchase and deploy end-to-end “solutions” for technical publishing such a MadCap Flare or Author-It. These commercial, proprietary products offer a set of authoring, data management, processing, and integration components that allow organizations with conventional publishing requirements to become productive very quickly. The folks at MadCap describe the appeal of their “solution” succinctly.
The MadPak Professional Suite includes five fully integrated technical communication and content development tools for authoring & publishing, analysis & reporting and multimedia creation. Tight integration between products, combined with MadCap Software’s industry-leading single-source and multi-channel publishing technology, provides you with a complete suite of tools for all of your technical communication and content development needs.
Each dimension of the publishing environment – authoring, content migration, content management, publishing, translation, customer analytics -- is addressed with a specific proprietary component. To extend the range of your pipeline, you buy additional, ready-to-install components. Everything that you can use right out of the box or customize is well documented and reasonably well-supported.
Like DITA-based “solutions” deployed in most large organizations, these solution suites are based on components and orchestrating interfaces. Unlike DITA-based “solutions,” the underlying components here are proprietary and captive. They are configurable, but not extensible. If your publishing requirements or cross-engineering integration requirements evolve beyond the boundaries of the purchased “solution,” you are in trouble.
Organizations expecting to purchase the equivalent components in the DITA environment are disappointed when they cannot order that ready-to-install DITA analytics component or that DITA context-sensitive Help manager. How can “Solution-DITA” call itself a standard if you can’t drop new DITA components into a pipeline and expect them to work without additional configuration or customization? How can “Solution-DITA” consider itself viable if it cannot get my group up and productive within a week of installing DITA editors, processors, and data management tools? Why aren’t all these components designed to work together right out of the box?
Folks assuming that DITA is a “solution” similar to MadCap Flare or Author-It have ignored the benefits of working with an open, vendor-neutral standard. The flexibility and extensibility designed into DITA as such a standard precludes there being any simplistic, plug-n-play orchestration across all interfaces and components. If our peer software engineering and test engineering organizations do not expect that GIT, Maven, Eclipse, Confluence, JIRA, Rally, Jenkins, or Stash can be deployed without significant optimization, why should technical publication organizations require that component-based publishing “solutions” require no optimization?
Perceptions Within the “Framework-DITA” Category
There’s a level of abstraction built into the DITA architecture that discourages limiting its operation and value to being an application (Tool-DITA) or a captive pipeline (Solution-DITA). The charter for the OASIS DITA Technical Committee uses terms such as “modular” and “model” and “extensible hierarchy” to describe the framework that it provides organizations seeking to develop standards-based publishing solutions.
DITA is an XML-based specification for modular and extensible topic-based information. DITA provides a model for defining and processing new information types as specializations of existing types.DITA populates the model with an extensible hierarchy of standard types.. . . Through use of a common specification, DITA content owners can benefit from industry support, interoperability, and reuse of community contributions. At the same time, through specialization, content owners can address the specific requirements of their business or industry.
In this context, the DITA standard engenders “strengths” when these goals of extensibility and interoperability are evident across DITA-compliant components and services. The standard exhibits a “weakness” when the standard inhibits or ambiguates extensibility and interoperability.
======
ALL DRAFT WRITING BELOW - SDoherty
======
Strengths
- DITA-compliant editors – usability, power, customizability
- DITA Open Toolkit – compliance, currency, documentation, feature momentum
- DITA-compliant component content management systems
- Technical solution forums
Weaknesses
- (Don) The originally provided Concept, Task, and Reference writing model does not satisfy all modern publishing requirements. In fact, DITA's design is agnostic about information architectures, and the CTR trilogy is but one relevant approach. DITA topics can be written to Every Page is Page One goals, for example, and alternative processing, developed as needed, can support most popular strategies for linking, collections, navigation, or output representation. Like life on Earth, DITA can be found thriving in extreme forms as data rather than as documents.
- Lack of an authoritative set of ready-to-use sample files illustrating all specified DITA features
- Lack of a DITA compliance test suite