Frank Miller, Comtech Services, Inc.
Recently, in the run-up to 2014 CMS/DITA North America Conference, we posed aquestion to the LinkedIn CIDM user group that we thought might elicit some clarifying discussions, but one we knew could muddy the waters even further. The question: Can we and should we manage content like we manage code?
The response was immediate, voluminous, and anything but harmonious.
Different Solutions to the Same Problem
On one side, there’s a group with a fairly strong opinion that there’s no significant difference between a code base that needs to be branched for new features, then merged back to the base, and an information set that goes through similar changes. This point of view argues that the fundamental process is the same and that the mechanics of managing, compiling (or publishing), and auditing the changes need not be any different—and in fact needs to be identical for integrity of both software and docs.
This group points out that in some cases the content IS the code and that in general, to crib a quote from one of the posters, “The line between content and code is blurring.” With this concept in mind, adopting the versioning tools and processes applied successfully in the software development world—SVN, CVS, or the like for centralized control or Git, Bazaar, and their kin (aka, DVCS) for distributed control, is not only a viable option but a preferred one. Using the same tools and processes ensures that your code and your content are developed and managed in lock step with one another.
But it’s more complicated than that, says the other faction. There may be similarities between software development and information development, but the differences are great enough that they need to be handled in unique, separate ways. To treat content as if it’s code, basic requirements can be met, but with limitations. In the best case, you’re missing opportunities, and in the worst case, inviting trouble.
The job of an information developer, particularly in a DITA XML topic-based environment, includes specific responsibilities and decision-making that version control systems were never intended to handle. Information developers make versioning choices based on a host of factors that coders are not faced with:
- the ability to manage differences with conditions, keys, and other metadata
- the impact of branching on shared content at multiple levels—map, submap, topic, element
- the need to publish changes, both for review purposes and public-facing delivery
- the need to see those published changes presented side by side in an easily digestible format so that merge decisions can be made
When it comes to merging, the process differences between info developers and coders remain, with an equally complex technical challenge thrown in for good measure. XML content needs to be merged at the block level, rather than the line-level-only awareness that is the standard functionality for code merge tools. For example, two authors have added their own <li> to the same <ul>. Differences need to be identified and resolved within the <ul>, which, as presented by most XML editors, will encompass multiple lines.
What it all seems to point to is that there’s a need for info dev-specific release management tools.
One Size Does Not Fit All
Most information developers will tell you that there are a lot of principles to adopt from the software development side and a lot of parallels to be drawn. Just as conrefs are analogous to code objects and keyrefs to variable passing, version control practices for software development can be emulated by information development groups. But the terrain that info dev has to navigate is always going to be inherently different, because of the nature of technical communication, of language, of words. Effective and scalable release management strategies will need to take content-specific requirements into account.
DITA 1.3 will contain release management enhancements and branch filtering capabilities. Component CMS vendors have built and enhanced their release management capabilities in recent years with input from some sophisticated, complex real-world use cases. And some very promising tools are being developed with the explicit purpose of tackling release management challenges specific to XML content.
The community is working on it. Some would say that release management solutions for XML content are in their nascent stages. If that is truly the case—and it seems to be—our lively discussion about content versus code is just beginning.