The Next Chapter for DocBook: What the OASIS DocBook TC Closure Means for Technical Communicators

September 25, 2024
Share
This is an image of a woman typing in a ccms

Earlier this month, the DocBook Technical Committee at OASIS officially closed upon a vote from its members, turning heads throughout the technical communication community. Does this mean that no one will be working on DocBook anymore? And if the DocBook OASIS committee is ceasing its activities, does that mean anything for component content management systems based on DocBook, like Paligo?

While the closure of its technical committee is certainly a significant moment in the history of DocBook, it has not come entirely unexpectedly. In fact, the end of the committee could be viewed as a sign of the technical communication community’s confidence in the time-tested maturity of the DocBook standard. But most importantly, the closure of the committee does not spell the end of the development of DocBook, nor should it cause any alarm to authors working in this particular structured authoring standard. Believe it or not, this might even end up benefitting DocBook moving forward.

Why Technical Documentation Standards Are Important

To better understand what this news does and does not mean for users of DocBook, it will help to take a step back and remember what OASIS is all about. No, not the English rock band, but the Organization for the Advancement of Structured Information Standards. OASIS is a nonprofit consortium that acts as a sort of organizational umbrella for people to collaborate on the development and adoption of open source and open standards projects.

These kinds of standards are a key part of what makes information interoperable among different systems and platforms. Imagine if you had to write your content in a system that could only produce its own proprietary format called “Acme Markup Language.” If you ever wanted to migrate your content to a new system, you’d be out of luck, since no one else has heard of “Acme Markup Language,” and you’d have no choice but to pay developers to spend an exorbitant number of hours deciphering your content and transforming it into something usable. That’s the kind of situation that standards are designed to prevent, and the reason why many organizations – including Paligo – choose to adopt an open source standard such as DocBook XML. This way, if you ever want to migrate your content out of (or into) our platform, you can do so with the confidence that other platforms will be able to ingest your content without issue. Meanwhile, we at Paligo can benefit from the insights generated by the wider community of developers working with the same standard as us, and we can stand on their shoulders when we develop our own platform.

How a Technical Committee Affects a Standard

The need for technical documentation to be written according to standards has long been widely recognized, resulting in a landscape of different standards that technical writers can choose from. Paligo chose DocBook for the relative flexibility and simplicity of its code. We found that authors can easily get started writing and publishing content without first needing to learn the complexities of the underlying standard. Of course, more important than the particulars of its XML content model is the fact that it readily enables the layers of content strategy that are most important to our organization, including smooth collaboration between multiple authors, single-sourcing, and translation efficiency.

The pace of progress for designing these kinds of structured authoring standards tends to be, well, slow. But that is by design. Every new proposal to change the standard, whether it’s a new element to add to the content model, an attribute allowed to appear in a new context, a rewording of the written specification, and so on, is carefully scrutinized for any possible way it may interfere with the other parts of the content model. The committee members deliberate each proposal among themselves and eventually vote on a decision. Those who are curious (and undaunted by arcane technical detail) can peruse the entire history of all votes and meeting minutes of any OASIS technical committee, or even become involved themselves as a contributor.

However, that’s not to say that OASIS is the only environment where DocBook can be discussed or developed. It could even be argued that the rigorous procedural requirements that dictate the activities of all OASIS committees have inhibited the speed of DocBook’s progress. As a matter of fact, depending on where the DocBook community moves next, this separation from OASIS may prove to be the impetus for accelerating new developments to the standard.

The truth of the matter is that the closure of the OASIS DocBook Technical Committee will likely go entirely unnoticed by the vast majority of people authoring in the DocBook standard today. That’s because the platforms that use DocBook, such as Paligo and industry-leading XML editors, still work the same as always, regardless of a handful of programmers meeting virtually every few weeks to discuss whether this or that DocBook attribute ought to behave differently in the upcoming release, for example. (Not to downplay the extraordinary level of expertise of those technical committee members!)

The important thing to realize is that it is not as if the DocBook standard had been updated at the conclusion of each technical committee meeting, with content-altering changes somehow pushed out to all the users of Paligo or some other DocBook-based component content management system. Rather, updates to standards such as these are released in major installments on an infrequent basis, oftentimes years apart. Furthermore, once these standards are released, they exist online forever for whoever chooses to adopt them.

Turning the Page

As a structured authoring language, DocBook is still as useful as ever as a way to structure your content so that you can take advantage of some of the most exciting new developments in content, such as AI and chatbots. Paligo, while it is based on DocBook, is at the end of the day its own project that exists apart from the DocBook standard. Organizations use Paligo every day to author, manage, publish, and single-source their content, proving that DocBook is very much alive and will continue to be for the foreseeable future.

A slowing of new posts to the OASIS DocBook Technical Committee discussion boards is less a sign that interest in the standard has ceased, and more an indication that the last wrinkles have been ironed out, the final bugs quashed, the remaining loose ends wrapped up. We thank the OASIS DocBook Technical Committee for their dedication towards creating and maintaining such a robust – and now, highly mature – standard that thousands of writers and communicators rely on every day.

Get started with Paligo

Paligo is built to meet the most demanding requirements, with plans made for any company from the growing SMB to the large Enterprise.

Book a demo
Share