Not so long ago, information could be neatly separated into data and content. Data was "structured" and stored in relational databases, OLTP and other hierarchical systems. Content was "unstructured" and consisted of, well, everything else. Data was what made the company go, so databases became a strategic part of the enterprise IT infrastructure. Everything else — at least the piece of it worth managing — was housed in special repositories called document or content management systems, typically deployed at the department level.

Today, as organizations struggle to keep information consistent and synchronized across print and Web media formats, global locations (and, thus, languages) and internal-, partner- and customer-facing business contexts, they're asking for content to be managed more like data. That means it must be easily reused, dynamically queried and custom-built, transformed into any presentation format and "processable" by application software. Whether they know it or not, businesses are asking for content expressed and managed as XML.

All types of content can be built on XML, which in turn is supported by the Internet's universal standards and low-cost infrastructure. It's far more IT-friendly than conventional content formats, which typically require information to be manually extracted into metadata to be machine processable.

Will XML's advantages, including content reuse, automation and compliance, lead it to become a pervasive form of source content? Initiatives underway in finance, the pharmaceutical industry and other applications point the way to XML adoption, but it may be years before the technology breaks out of niche applications. In the companion article, "Reuse Content Without Starting From Scratch" http://www.intelligententerprise.com/showArticle.jhtml?articleID=163105099, we'll explore how McDonald's, Hilton International and manufacturer Emerson Process Management are making the most of their content without XML-based management.

Blurring the Line

Through waves of the software industry's consolidation, content management has remained stubbornly distinct from data management, rebuffing the DBMS giants' periodic attempts at absorption. That's because data and content are fundamentally different. Data is structured and self-describing (records and fields have defined names, types and relationships), and thus it's machine-processible. Using a universal language (SQL), data can be queried and retrieved at any level of granularity, from an entire table down to an individual field. Visual data presentation in report tables, charts and other views is an application-level function distinct from the data itself. Data is pure information.

In contrast, content doesn't cleanly separate text information from presentation formats defined by applications such as Microsoft Word, Adobe Acrobat and HTML editors. Content objects are information views, optimized for processing by people, not machines. The unit of retrieval is a document or file. While you can search for content based on tiny information fragments, as small as a single word or character, what you retrieve is a list of documents, not the fragments.

Being unstructured, content isn't self-describing, so it must be linked to external structured elements called metadata to allow searching by title, author, creation date or application-specific elements such as customerID. You can query the metadata or text-search the content, but not both at once.

So what's the problem? Compared to data, content is hard to reuse, cumbersome to search and generally resistant to automated processing. To reassemble content fragments in new contexts — from financial statements to press releases, for example — you must find each fragment inside its respective source document, then cut, paste and reformat. Because content is managed at the document level and information is inextricably tangled up with presentation formatting, manipulation is largely manual and inefficient.