Really interesting discussion so far with many
insightful comments from the trenches.
Michael's comment, "DITA can be complex, if you
need complexity. It can also be simple, if you need
simplicity" is true, however the issue seems to be that the
*default* state of DITA is complex. In practice there is a
world of difference between "DITA has 100 elements and you
can add up to 100 more via optional packages." and "DITA has
200 elements and you can hide up to 100 of them by
As a general statement about technology, users
overwhelmingly stick with defaults, much more than
developers usually think and in spite of what experts
recommend. Here is one example: http://www.ingentaconnect.com/content/routledg/rics/2008/00000011/00000001/art00003
. There are a few reasons people tend to stick with
- Choosing what to change means reading a big
pile of stuff
- Afraid that if they turn something off, turning
it back on will be a huge hassle or impossible
- Not easy to get budget approval for taking
features out of a product and putting them back in later
- Too busy with other critical tasks in getting
the project off the ground
- Nobody ever got fired for sticking with
defaults in software
In addition to the tendency of users to stick
with defaults, I think another thing going on is unit bias (http://sciencethatmatters.com/archives/35).
Many, although not all, vendors like to be able to say that
they "fully support" something without a bunch of footnotes
describing the 17% that isn't supported.
BTW, so far we've been focusing on the perceived
complexity of the standard itself, but I'd guess that a lot
of the complaints about "DITA" being complex refer to issues
with tools, and particularly with customizing output. There
isn't really anything we as OASIS committees can do about
tool issues, but it's worth keeping in mind that people
aren't always talking about the standard when they talk
about DITA's complexity.
JustSystems Canada, Inc.
1 (778) 327-6356
Community Forums: http://forums.xmetal.com
partners only: http://www.justpartnercenter.com
>The "DocBook is dead"
undercurrent in this thread surprises me.
I hadn't noticed
that undercurrent, and don't think it's relevant to the
discussion in any case. Getting
But I do think
that just saying "DITA is complex" is a complete mistake.
DITA can be complex, if you need complexity. It can also be
simple, if you need simplicity. There are plenty of case
studies from both ends of the spectrum. Boosters of DITA
tend to focus on the simplicity of the simple cases and the
value of the complex cases, and detractors of DITA do the
reverse. Both are misleading.
A big driver for
the creation of the DITA maturity model was to bring some
clarity to the discussion. At level 2 of the model, you're
using just topics and maps, and only prepackaged
specializations (if any). Many organizations adopt at that
level and are quite happy with their ROI. You get the
potential for substantial additional returns from higher up
the model, along with increased cost - although over time,
there is a trickledown effect, as specializations created by
organizations at level 3 or higher are tested and
contributed back to the community, allowing groups at level
2 to capitalize on that investment.
Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
The "DocBook is dead"
undercurrent in this thread surprises me. DocBook is still
alive and well in many applications, esp., open source.
Even with more elements (though if you include L&T,
DITA 1.2 is bigger than DocBook 5.0:-), I'd argue that
DocBook is much simpler for writers and will be until
practitioners learn how to use the complex features of
DITA to create simple applications that support the work
that writers need to do.
(By "application" I mean a combination of
specialization, features like keyref, content strategy,
and writer training to create a custom solution that
addresses a particular business need.)
I wonder if the correct "marketing" approach is to
acknowledge that DITA is complex, but emphasize that when
properly used, that complexity makes it possible for tools
developers to create applications that are simpler and
more capable for their target audience.
To unsubscribe from this mail list, you must leave the
OASIS TC that
generates this mail. Follow this link to all your TCs
in OASIS at: