DITA XML reuse is a godsend to busy writers trying to keep ahead of the information deluge they are responsible for. If Jane wrote a topic to cover the benefits of SpiffyNewProduct in her datasheet, then Dave can reuse that benefits topic in his design guide, and Jo can reuse it in her deployment guide, etc. etc.
Great stuff! But what happens if Jane’s topic wasn’t written to the latest corporate style? Or if Jane was a junior writer in a separate department from Jo? Jo is left with the options of:
- Writing her own topic to the latest corporate style.
- Negotiating with Jane and Dave to edit the existing topic to improve it.
- Just grabbing the existing topic, warts and all, and getting on with her own project.
How many writers do you think choose option 3? In a fast-paced environment where project schedules already assume reuse and not rewriting, more writers will pick the easy option of grabbing what’s there instead of improving on it.
Then there’s the other source of bad writing – legacy content that has been run through a script to convert it to XML. There again, we get large volumes of XML topics not necessarily written to today’s standard.
Bad writing can get reused just as well as good writing. In the perfect world, we each work toward improving that bad writing, to the benefit of new content, and republished old content. Part of XML projects that include reuse must include time for improving and adapting those older topics to today’s writing standards. It’s not a drive-by window for grab-n-go authoring..
- Content Reuse the Easy Way (tc.eserver.org)