MHonArc v2.5.0b2 -->
dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] Thoughts On Sections
One of the goals of instituting a new way of authoring and often a new
content management system is to begin with sound content. It would be a
better decision to leave legacy content out of the new system. You can
refer to it, include it in maps, but otherwise acknowledge that it does
not meet the new standards.
If you spend much time and energy simply converting legacy content that
does not comply with a topic-based model, what have you accomplished?
For years, we saw organizations convert legacy content into XML DTDs
that emulated their existing information model perfectly. Aside from
possible cost savings in decreased production time, they didn't appear
to have gained much except to create an environment that made it more
cumbersome to author and review content.
We need to have a discussion at some point about the process of
migrating to DITA. My advice to organizations is to transform the
content rather than migrate. Unless the legacy content is reasonably
well structured, you will end up with a repository or a collection of
topics that is not essentially different from your starting point.
I don't believe it's the small organizations that have a problem. With
less legacy content and a solid analysis of what should be transformed
and what should be left outside of DITA/XML, small organizations with
continuously changing information should be able to transform their
existing content quickly and move to authoring new content. It's the
industries like telecommunications with enormous legacy content that
have a problem that requires thorough analysis and tough
decision-making.
One of the primary advantages of the DITA model is to reduce the cost of
change in the future. Migrating legacy content "as is" simply maintains
the status quo. The content is still largely unworkable. Transforming
content to meet the model means that you will have a database that is
pliable. Given 20 years of desktop publishing, we have created a legacy
of content that is incredibly expensive to change, as Rob and Paul have
both noted in their examples. If you do nothing to reduce the cost of
change, why bother to spend all this time, money, and energy moving to
DITA/XML?
We might want to consider the concept of "technical debt." We have
gotten ourselves into a huge technical debt with the way we have
produced technical content for 20 years. Now seems the time to reduce
the debt. I think the difficulty of decreasing costs is one reason for
the stampede to outsource technical documentation to low-cost work
forces.
As you can tell, I'm quite passionate about this issue.
JoAnn
JoAnn T. Hackos, PhD
President
Comtech Services, Inc.
710 Kipling Street, Suite 400
Denver, CO 80215
303-232-7586
joann.hackos@comtech-serv.com
www.comtech-serv.com