Threading Your Way Through E-mail: XML Organizes Electronic Communication

Robert Carter

January 27, 1998

Introduction

Tired of wending your way through convoluted e-mails in which everyone has felt compelled to give more than their two-cents-worth? Lost in a sea of ">"s? Have no fear, XML is here.

It offers the ability to structure the flow of an e-mail discussion in a more intuitive, logical, and flexible format.

Actually, Extensible Markup Language (XML), Cascading Style Sheets (CSS), HTML 4.0, and a small coterie of working drafts before the Internet Engineering Task Force (IETF) all contribute to the new HTML Threading proposal recently accepted for submission by the World Wide Web Consortium (W3C). (See http://www.w3.org/TR/1998/NOTE-HTMLThreading-0105.) The proposal was authored by representatives of Microsoft, QUALCOMM, and Lotus—a noteworthy collaboration. (Note that "Accepted for submission" means the W3C will convene a panel of experts and interested parties to review the proposal; it's the first of several steps that ultimately may lead to a W3C recommendation of the proposal to the Internet community at large.)

Building on the E-mail Infrastructure

This latest submission to the W3C expands the capabilities of existing (and proposed) e-mail standards. It does this by providing the "user agent" (standardspeak for, in this case, some kind of e-mail application software) the means to discern by whom a message (or part of a message) was sent, when it arrived, and what kind of formatting or display information should be attributed to it.

While this may not sound like an earth-shattering event, it is nonetheless significant. It offers the ability to structure the flow of an e-mail discussion in a more intuitive, logical, and flexible format. I will show why (and how) using a whimsical example. Note that the features I present may not ever make their way into e-mail software. The standard could change, or e-mail application vendors could decide not to adopt specific features. (In other words, actual applications may vary.)

An Example

Let's say I sent an e-mail to my good buddy George discussing the metaphysical significance of Pismo Beach in Bugs Bunny cartoons. If my e-mail application were using features enabled by the HTML Threading proposal, I could use CSS to specify the exact formatting I wanted to apply. (Since I would configure my e-mail formatting from within the application, I would probably have no idea the formatting was getting communicated to other browsers via CSS.) Adding HTML capabilities to e-mail will also provide greater flexibility. For instance, instead of indicating a "mailto:" as an authorial reference, I could specify a URL instead.

After George read and reviewed my piece, he could embellish the interpretation of the "left turn at Albuquerque" reference, offer a counterpoint to the "Daffy Duck and Coleridge's Albatross" section, and forward the now-heavily-edited piece to Nancy for review.

When Nancy opened the message, my original insights would appear without the ubiquitous ">" at the beginning of each line; instead, they would reference my style sheet and be displayed accordingly. If George used CSS, his additions would appear with his style template applied. (This would occur even if George inserted his comments inside my original text.)

Nancy would have several options on how she could display the threaded message. She could accept and display each of George's and my styles as they were intended (by referencing the respective style sheets), or she could apply her own default style (which would still delineate each person's contributions, but in a fashion she preferred). She could arrange the thread by date. She could even apply a filter that would remove George's additions entirely. Or perhaps she wouldn't have any of those options, because her e-mail application didn't support HTML Threading.

While this example scratches the surface of the HTML Threading proposal, hopefully you have an idea of what capabilities it brings to the table for collaborative, multi-party electronic discourse. If you have any doubts about its usefulness, I encourage you to rifle through your mailbox or the discussion trees of particularly active newsgroups. Any complex or contentious issue is bound to have multiple conversational threads spread across a large chunk of time, with lots of people responding to different parts of the thread. Tracking a conversation from beginning to end (or, if you've been following the discussion, from end to beginning) can be onerous—especially if it isn't moderated, and multiple e-mail clients are involved.

Summary

The HTML Threading proposal could enable e-mail software developers to create a set of tools to manage the complexity engendered by the inherently collaborative nature of electronic communication. E-mail has evolved a great deal from its humble mainframe-to-mainframe ASCII origins. Standards such as Multipurpose Internet Mail Extensions (MIME) expanded e-mail's ability to include files and graphics, and are currently expanding to include HTML. Now, threading builds further on the foundation by explicitly tracking the relevant elements and parameters of an e-mail "conversation," and providing display control for them to present message content in its clearest light.

If you are interested in a more comprehensive discussion that references the respective contributions of XML, HTML 4.0, CSS, and the other standards involved, I highly recommend reading the proposal for yourself. You can also read the press release accompanying the announcement, where you can get the perspective of the companies that collaborated in developing the proposal (Microsoft, QUALCOMM, and Lotus). The Site Builder Network standards page is also an excellent resource to track the status of the proposal and find copies of the latest working drafts.