RE: [dita] who complains about complexity of DITA?

Greetings all

“Complaints” might be too harsh, but the disquiet that I have heard comes from authors. I believe the issue is one of perception, not of complexity, but that doesn’t necessarily make it a lesser problem. From chats that I was involved in (or overheard), there is some feeling that DITA was OK as it was, and that the drivers for the 1.2 changes and additions are unclear. (“Who decided there was a need for keyref or whatever?” “I’m going to stick with 1.1, because I don’t need any new features.” “I can see that keyref is very clever and so on, but I can’t foresee ever needing it.”)

A comparison with DocBook was also made, along with a view that the demise of DocBook was connected with the growth of its number of elements.

The question for us should be how do we address this perception of complexity? It is quite difficult to explain specialisation and conref to a novice, but we now need to also be able to explain constraints and keyref, subject schemes, etc.

Tony Self

From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Tuesday, 7 December 2010 3:16 AM
To: Bruce Nevin (bnevin)
Cc: dita@lists.oasis-open.org; dita-adoption@lists.oasis-open.org
Subject: Re: [dita] who complains about complexity of DITA?

I'm also curious about this. Even before we had constraints, we had basic DITA modularity, which lets you include or exclude whole domains of elements at a time. And the doctypes we package with the spec do exactly that.

Simple number of elements in the spec as a whole shouldn't be a measure of complexity for either authors or architects, since you only include or work with the elements that matter for your domain. For example, the learning and training specializations don't increase complexity for authors or architects in basic tech comm.

So do we really have a complexity problem, that is it's too hard to use DITA or create new DITA specializations? Or do we have a communication problem, about how to use DITA (start small, include what you need, don't try to use stuff you don't need)? Or are there other problems, outside the domain of the spec, like customizing processing flows, that get reflected back on the spec even though it's really something outside our control?

I don't mean to dismiss complaints about complexity, but like you I think we need to understand the actual motivations/causes of the complaints before we can usefully react.

Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

dita-adoption message