Latest posts by techwriter (see all)
- 15 Questions to Ask After You Finish a Technical Document Project - February 12, 2018
- THY’s Perfect Information Design - February 9, 2018
- Waterfall vs. Agile Models in Technical Documentation - February 7, 2018
© 2010 Ugur Akinci
There are two excellent reasons why you should learn XML as a technical communicator, both argued well by Jabin White at his seminal post “XML is Here to Say (I Promise)“.
The first reason is: XML is platform and application independent. When you create an XML-tagged document, what you’re creating is nothing more than a plain text file. That’s why you do not in fact need any specialized XML editors to generate an XML file. Notepad is all you need. But XML editors have all the bells and whistles that make life much easier of course. But the fact remains that XML is nothing more than a special way of placing tags around text components.
Since XML is nothing but plain text with no style guidelines/attributes attached, you do not need any one particular application to display it. That’s not the case with content created by other applications.
Let’s take FrameMaker, an editor I love. If you have FM7 or FM8 and someone sends you a FM9 file, you can’t open it unless you have FM9. But you can feed an XML file into any application you like, whether it’s FM8 or FM9.
Similarly you can use MS Word or any other popular word editor to import your XML-tagged content. However if you’ve created your content with MS Word 2007 (let’s say) you’ll need Word 2007 to read that, or something like OpenOffice 3.0 which can open and read all Word files. Still the point is, you’d be application-dependent. Not so with XML.
This brings us to the second point the JW makes: your XML files will “survive future” since no matter how much specific applications change, your text-based XML file will always be accepted and rendered by any future application.
XML is at the heart of all future documentation and publishing. It’s the smart thing to do to learn it well.