No, I didn't miss it. It's a good graphic. In fact, its this graphic which lead to to make my point. The graphic is entitled "near term", but it also includes things like APIs, repositories, IM, Yahoo! Groups, and "tools". All great things, but my point was just that I think these should be part of a subsequent "release".

If indeed the current thinking is to first implement and deploy a very simple system (with real users), then I did miss that. :-)

Well you're right. I apologize - I was being too optimistic.

Should I take off all other systems besides QuickTopic and one other topic guinea pig?

:-)

< replied-to message removed by QT >

I like your graphic too, Marc, and I want to get there. I think we can show something useful before we have APIs, just in the form of import/export.

But enough talk -- let's freakin' do it! Who wants to export, who wants to import? Export is easy, so I can have that done quickly in QT, in RSS1.0 or RSS2.0. I'll write an importer too, if someone wants to export.

This isn't to say that the spec is done, but for myself, it'll give me a kick in the pants in helping define the spec if I have someone to work with. It's lonely all alone in my basement :-)

We'll ready to hand the WebOutliner source to anybody who wants to use it - within a month. Then someone can EDIT a ThreadsML - in an abstract sense - and send it/route it - anywhere.

< replied-to message removed by QT >

> We'll ready to hand the WebOutliner source to anybody who wants
> to use it - within a month. Then someone can EDIT a ThreadsML -
> in an abstract sense - and send it/route it - anywhere.

Cool. Will it import and export ThreadsML at the time of release? RSS1.0, RSS2.0, or both?

Shall I write an importer for QuickTopic?

HHhhhhmmmm - that would assume:
 - resources
 - we grok what ThreadsML is
 - resources

Did I forget to say "resources?"

:-)

< replied-to message removed by QT >

Those pesky resources. Anybody with resources out there to levitate us from the Land of Theory?

Going once.....

Going twice.......

Oh well - I guess we'll have to do it ourselves.......

< replied-to message removed by QT >

Following up on my earlier message, I have created an MT template that produces an RSS 1.0 feed of a thread. It is based entirely on the default "RSS 1.0" template that comes with MT v2.63 -- I just used MT tags to change the content between the RSS tags, I didn't modify the RSS tags at all. I say "RSS 1.0" in quotes because I am still learning about these formats -- I don't know enough to say that the MT format is "valid" (Marc will tell me that this is why we need a validator ;-)

I have set up autodiscovery on my individual archive pages (these pages include all comments + the orginal post, so it seems the best basis for the "conversation" thread). Using a desktop aggregator, this works very well -- I can subscribe to threads that I want to monitor (I put them all in a "Conversations" folder). Aside: I often find that blog comment discussions are often left hanging. Someone posts a comment, the author might respond, but often times the comment-maker does not return to discover the response (it can be hard to remember and track all the blog comments you have made). Even the ability to subscribe to threads using a desktop aggregator has significant value.

Of course, the next step would be to aggregate such feeds into a forum-like web interface....

Here are some screen shots and links to what I have done so far.

Mark Carey wrote:
> I have set up autodiscovery on my individual archive pages
> (these pages include all comments + the orginal post, so it
> seems the best basis for the "conversation" thread). Using a
> desktop aggregator, this works very well -- I can subscribe to
> threads that I want to monitor (I put them all in a
> "Conversations" folder).

Nice! Are you putting the entire contents of each post in the <description> element? It would be great if you could use the content module
(http://web.resource.org/rss/1.0/modules/content/) and put your full text in there. That would be a step closer to the current proposal for ThreadsML (http://www.quicktopic.com/7/H/rhSrjkWgjnvRq/m66).

What aggregator are you using? Is it something you can hack to display message content as a <content> element?

I've just updated QuickTopic's RSS1.0 output to use the content module as described at the above URI (did I miss this originally or has it changed?). Previously it was given as a bag of items -- this is less complicated. You can of course see this thread as close-to-ThreadsML (RSS1.0-compatible) by adding .rss to the end of a QT topic URI, e.g.:
http://www.quicktopic.com/7/H/rhSrjkWgjnvRq.rss

>Nice! Are you putting the entire contents of each post in >the <description> element? It would be great if you could >use the content module
>(http://web.resource.org/rss/1.0/modules/content/) and put >your full text in there. That would be a step closer to >the current proposal for ThreadsML >>(http://www.quicktopic.com/7/H/rhSrjkWgjnvRq/m66).

Yes, I am putting the entire contents into <description>. As I said, I am fairly new to these formats, so I just used the MT layout. I will take at the content module URL to learn more about that. I am using Newz Crawler 1.4, and when I learn more about the content module, I will comment on that ;-)

>Technical summary:
>Use RSS 1.0 and require the standard Content module.

Okay, I have taken a quick look at this. I also subscribed to the feed for this thread with Newz Crawler -- the content data doesn't show -- couldn't find a preference to make it show.

Please excuse my ignorance, what is the benefit of using the content module and why is this "required" in the current proposal?

TIA for educating me,

Mark

Mark, here's my take on this:

RSS1.0 was intended for syndication, where usually the end-user will be reading a list of headlines and brief descriptions and going to the orignal posting site to read the full content.

ThreadsML's purpose is to allow saving or moving the entire contents of a thread (and having the capability for representing the branches that threads have, unlike plain RSS). Making it a superset of RSS1.0 (and/or RSS2.0) gives us compatibility with the RSS usages, and using a separate content module lets readers/importers that support it add extra capabilities.

BTW, given the amount of "resources" available to work on proofs of concept, I'm really glad that we're building on RSS, since there are already interesting uses and lots of apps for that. It'll provide some necessary momentum.

This is a perfect explanation of the ThreadsML logical strategy.
1. Leverage existing standards where possible
2. Get others to work on an a piece of an inter-locking puzzle
3. Focus on real-world examples
4. Enables LOTS of cool new stuff

So the issue of embedding ALL the content into the RSS feed may seem strange, but it's exactly that sort of un-anticipated usage of
technology - that Clay Shirky talks about - that separates the ants from the robots.

The analog inside of us - looks at what's available and we say
(collectively) "what's the shortest distance to get us from here to there?"

RSS (in whatever form) has always seemed to be to be the bext transport vehicle - because it's already being used - as an amazing standards for content syndication.

But why stop there?

Paolo and Matt haven't stopped? Ben hasn't stopped? Steve hasn't either.........

< replied-to message removed by QT >

Edited by author 05-22-2003 05:34 PM
>ThreadsML's purpose is to allow saving or moving the >entire contents of a thread (and having the capability for >representing the branches that threads have, unlike plain >RSS). Making it a superset of RSS1.0 (and/or RSS2.0) gives >us compatibility with the RSS usages, and using a separate >content module lets readers/importers that support it add >extra capabilities.

That helps, but it doesn't fully answer my question. I understand that the original intent of RSS was to provide excerpts with links to "full stories". And I understand (as Marc alluded to) it has become used by bloggers to embed the entire content of each post (in the <description> tag). My question was/is: what extra benefit is derived from placing the entire message within a <content> tag (like the QT feed) versus placing the entire content within the description tag (as I have done)? With the message in the description tag, I can use existing aggregators to read entire threads, but I can't read data in the content tag. Perhaps what I am missing is the "extra capabilities" that the content module provides -- what are examples of such capabilities?

Thanks,

Mark

OK dudes

I've collected some juicy bits and two screen shots at:

http://www.quicktopic.com/cgi-bin/thwiki.pl?WebSiteCopy

Feel free to take this raw stuff, copy edit it, and turn it into some spiffy web site language. Now is the time for wordsmiths to do their thing.

Ben & David - this means you.

We need a site that says:
 - what ThreadsML is
 - it's status
 - our evolutionary approach
 - some use cases
 - what the evolutionary phases will be
 - and an FAQ

Seem reasonable?

- Marc