I've added some concrete stuff to the proposal at

http://www.quicktopic.com/7/H/rhSrjkWgjnvRq

Here's the message I just posted. Please add your feedback and additions,
there or here (I'll probably cross-post anything here to there). Or you can
cross-post by mailing to qtopic+7-rhSrjkWgjnvRq@... as well as
rss-dev@yahoogroups.com.

Thanks,
Steve Yost
-------
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 <a>and</a> 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.