Edited by author 05-22-2003 10:33 AM
It's time to go further with a concrete proposal. Awhile back, David Weinberger, Rael Dornfest and I had an impromptu conference call to gather agreement on the motivations and priorities for the standard. My notes are slim, but one key point was how to deal with threading. Some applications implement branched threads and other like are linear or have pseudo-threading like Quick Topic.

Technical summary:
• Use RSS 1.0 and require the standard Content module. (for example see Quick Topic's current RSS format). Optionally use the Dublin Core module for added details.
• For optional threading, use the proposed Threading module to represent parent-to-child relationships and use the Annotation module to represent child-to-parent relationships. [Its description answers any reservations about its name: "Provides support for resources that annotate, follow-up to, or reference other resources." (my italics)] If you want to support threading, both are required, but support for threading is optional.

Question: Where applicable we want to represent relationships within the XML file rather than pointing back to the original resource (so the file alone would be sufficient for an import operation). How does a child node refer to another item within the same file? How does it refer to a specific item in a different resource file? I guess it comes down to "what's the granularity of a resource in the RSS 1.0 framework"?. (The same question applies to parent pointers.)

Use case
ThreadsML should be able to support the following:
A user exports a thread from a source application that supports threading. He defines its boundaries in whatever way the the application provides. The thread may include forked branches, i.e it may have a non-linear, branched structure (though there is an underlying chronological sequence of messages). The export is saved to a file.

a. He then imports that thread file to a destination application. The destination application only supports a linear representation, so it presents the messages chronologically. At the thread boundaries (in this case before the first and after the last message), Previous and Next links in this application can optionally direct the user to particular messages in the source application from which the thread was originally exported (i.e. there should be enough information in ThreadsML to support this).

b. Later, the user exports another thread from the source application, picking up chronologically exactly where he left off before, and imports it to the destination application. The destination application recognizes the first item in the new import as the successor to the last item in the previous import and represents this appropriately to the user.

This is all an extension of the conversation I mentioned, and while it owes almost everything to the other participants, they aren't accountable for my extrapolations from it. This is all flexible and in the works. Feedback is welcome. I'm especially hoping to hear from you, Aaron, but all others too.