“If you could start your docs from scratch, what formats would you be delivering & what documentation infrastructure would you be building?”

This was the question that kicked off a lively discussion in the Documentation and Technical Writing Management group on LinkedIn.

When it comes to deliverables, the answers run the gamut: HTML5, video, mobile, PDF. The answers to the documentation infrastructure part of the question, however, over a third of the respondents (at the time of this publishing) say they’d choose XML.

What is XML?

XML stands for “Extensible Markup Language,” and defined by Wikipedia, is “a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable.”

W3schools.com says that “XML was designed to transport and store data,” and “HTML was designed to display data.”

XML isn’t just for technical communicators. As a matter of fact, XML is a very common way to transport data, so a lot of software developers use it.

Why XML?

Well, according to some of the people on the LinkedIn thread:

  • XML - for better integration with the product's code
  • XML for sure, to be able to select almost any output including PDF and for easy integration with development systems
  • I would use XML to keep structure and format separate

All of the content in an XML document is consistently structured, which means that authors are conforming to universal standards while writing. With XML, content is separate from formatting and therefore allows the author to focus on content creation. This makes re-using content, maintaining consistency, and increasing productivity a lot easier.

XML and MadCap Flare

Flare content conforms to industry standard XML requirements, which means that Flare content can be edited in the Flare XHTML Editor, in external editors, or transferred back and forth between the two at will. This also makes Flare’s code easy to integrate with other XML or XHTML applications.

All Flare files are separate XHTML and XML documents—topics, TOCs, browse sequences, targets, skins, snippets, glossaries, destinations, condition tag sets, variable sets, and more. This means that Flare projects are completely open, transparent, and accessible.

Even if you do not know anything about Extensible Markup Language, you can use Flare to create XML content (in Flare's main content editor and other editors). Plus, if you want to work directly in the code, Flare’s split-view editor allows authors to see both the underlying XML code and the WYSIWYG editor side-by-side, in real time.


Learn more about XML (W3Schools.com), or download a free 30-day trial of Flare here.