DITA versus DITA-OT!
For years, almost everybody in the world of DITA has at some point confused DITA and DITA-OT. Who owns what? How are they developed? As one of the few working on both, I may also be responsible for at least some of the confusion. So, here is my view of the differences. Also, diagrams.
What is DITA? | What is DITA-OT? |
---|---|
|
|
Who governs DITA? | Who governs DITA-OT? |
---|---|
|
|
How does the OASIS DITA TC direct work on DITA-OT?
TL;DR version: it doesn't.
The OASIS DITA TC sets rules for how DITA works, such as how to process the
@conref
and @keyref
attributes. DITA-OT and every other DITA
implementation must follow those rules. In that sense, DITA-OT (like any other DITA
implementation) is guided by the OASIS DITA TC.
The OASIS DITA TC has no control over other aspects of DITA-OT, such as default styles or
processing parameters, just as it has no control over how an editor or CMS renders elements that use
@conref
.
How does DITA-OT get updates to DITA itself?
TL;DR version: it doesn't.
For each new version of DITA so far, DITA-OT was the first implementation to try and implement a lot of new features (not all of them, but certainly many). Experience implementing those features led to feedback on the specification. For example, with DITA 1.3, Jarno Elovirta (DITA-OT's lead developer, and again, not an OASIS member) sent in many public comments as he tried to test out and implement the early draft specification. Some of that feedback led to changes in DITA 1.3 – but Jarno himself had no vote in whether or not his comments were accepted. Whether to accept his suggestions was entirely up to the voting membership of the OASIS DITA TC.
Of course I personally play a confusing role as both a developer of DITA-OT and an editor of the specification at OASIS. Without question, my experience working with DITA-OT influences how I evaluate new feature proposals at OASIS (as I think it should). At the same time, my responsibility at OASIS is to represent my employer (IBM), not DITA-OT. As editor of the specification, my guiding principle is to ensure that the DITA specification is defined in a way that is not dependent on (or a barrier to) DITA-OT, or any other DITA implementation.
Summary
There are a lot of reasons to confuse DITA with DITA-OT.
- Both came from IBM at the same time.
- The names are, admittedly, quite similar.
- Both are "open" (I've heard longtime users mistakenly call DITA "open source"; I've also heard DITA-OT mistakenly called an "open standard")
- Both rely on volunteers (or on companies that volunteer employee time). Come join either one! Or both!
- DITA-OT is bundled with so many DITA tools that some have suggested it should be a standard, or a "reference implementation", regardless of other implementations. Possibly of interest: I've heard that suggestion from participants in the OASIS DITA TC; more often, I've heard it from people who do not participate in either group. I've never heard that suggestion from current or recent contributors to DITA-OT.
- Most DITA authors are working with one or more vendor tools. Very often, those are marketed as DITA tools that support DITA using DITA-OT. It's never easy to tease apart such differences without getting really deep into the details.
With all that, it's not surprising that DITA and DITA-OT are confused. Regardless: they are not the same. There is no official connection between the two. While there is some overlap in purpose (support content using DITA), and at times in participation (ahem), neither group can or should direct the other.