Arbortext: The First DITA Editing and Publishing System

The first mention of public DITA support for Arbortext dates back to a press release by Arbortext on April 20th, 2004. In less than a year (June 2005), DITA was first approved as an OASIS standard. But the earliest mention of DITA was in March 2001, three years earlier. For DITA to be a fully-fledged specification and already supported by Arbortext, means that Arbortext was in the process of supporting DITA for several years leading up to the spec's public release.

What many people don't realize is that IBM was using Arbortext when they developed DITA. In fact, in the years leading up to its release as an OASIS standard, Arbortext was the primary XML authoring tool at IBM. In fact, at the time of the first release of the standard, Arbortext was the only XML authoring and publishing application vendor (original call for participation) to be part of that initial TC (announcement) to approve DITA as an OASIS standard (ballot).

I remember this quite vividly because I presented at ACM SIGDOC in 2002. My presentation happened to be right before Michael Priestly's. He and IBM had started really promoting DIT to the world and I remember him asking me why we didn't choose DITA at Juniper (this was the subject of my presentation). I remember the question because we had considered it. I just hadn't been ready when we started our project two years earlier. We may have missed DITA but we ended up with the same toolset that had supported its development.

In fact, Arbortext supported many DITA features long before they were added to the DITA spec. Features that were integral to our selection of Arbortext back in 2000. 

Take DITAVAL, for example. DITAVAL is used to add conditional processing during a specific output, build, or other purpose. The ability to add profiles to XML content and processing was one of the early capabilities in Arbortext and was spec independent, making the ability to profile content available to any doctype authored in the tool. Arbortext's profiling mechanism was how IBM did profiling prior to the invention of DITAVAL. DITAVAL wasn't even part of the DITA specification until DITA Version 1.1 -- OASIS Standard, 1 August 2007, two years after the first public release of the spec and nearly a decade after Arbortext delivered the same capability. 

Arbortext and DITA have a long history. Because of that history, publishing, styling, and authoring DITA is easy in Arbortext. So is managing DITA content in Arbortext. If you've got both, you've got a leg up. No messing around. Solid history and technology is there to support you every way you need.

Update: 2022-05-22

Reading this article, I noticed that I failed to mention the other major reason we chose Arbortext. It's not something I've written much about, as it turns out.

Our other major motivation for selecting Arbortext was it's extensive API. Every menu item, every function, in every application they produced (Editor, Publishing Engine, etc) is accessible through an API. IBM used the API to build an extensive Workbench application that automated and facilitated author work habits. We had intended to use it to extend data merge--automating partial document creation from other business systems. While we did some things, our complete vision wasn't fully manifested before I left Juniper in 2005.

It should be noted, however, that the API is still there today. Many customers still use the API to connect to other content management systems like Contenta or Simonsoft, or to support group-specific menus and commands to help writers be more efficient for their content, customers, and processes.

In fact, the API has been expanded over the years and is more easily accessed in 2022 than it was in 2000. If you're curious, in the early days the API was accessed through a C-style code library called Arbortext Command Language (ACL). Finding ACL programmers has always been rare, as you'd expect from any vendor-specific programming language.

While full support for ACL still exists, it has been augmented with a java-based library since at least the 6.0 release and the publishing engine has added even more support (perl, javascript, and css) over the years, making it a lot easier to find talent that can pick up and do anything they want with the Arbortext UI and processing pipelines. Something nearly no other tools can claim.

You might also be interested in...