Archive of UserLand's first discussion group, started October 5, 1998.
A common syndication format?
Author: Dave Winer Posted: 7/2/1999; 6:21:58 AM Topic: Syndication formats mailing list Msg #: 8047 (In response to 8044) Prev/Next: 8046 / 8048
OK, in the spirit of opening this up, a progress report.
I've spoken several times this week with people from Netscape on the next step with RSS and
. I proposed that we agree on a single format, and a loose way of moving forward in the future.
To me, the single most important thing is to maintain a non-rigid attitude, to be focused on what I want, and not be overly concerned about stylistic issues at the XML level. The goal is to enable interesting apps, and to do it in an open way so no one feels the need to blaze their own trail.
Netscape isn't of one mind on the subject of ownership. Some people (apparently) believe that it has to be shared, and others are very clear that RSS is a Netscape creation.
Philosophically, if the "we own it" approach wins at Netscape, then there *will* be more than one format. I know this because there already is more than one format. As I said to Netscape people yesterday, "We are working with many other developers, it won't do to tell them to 'talk to Netscape' when they want us to accomodate their needs."
We renewed development of
format because Netscape was going forward, against their stated intentions, without us in the loop. They were evolving RSS to meet their needs, but ignoring ours. Which is their choice, nothing wrong with this, but we have to respond accordingly if we care about this market, which we do.
So, without the direct involvement of Netscape, let me state what I have proposed to them publicly, so at least you know what I want to see happen with RSS. Your opinion may differ. However if you can get behind this as-is, this will allay a fear that Netscape has, that the spec will bloat and get uncontrollable and most important, be unimplementable on their server. These are legitimate concerns, we share them. We won't support creeping featuritis-type growth in either spec.
For the purposes of this discussion, please refer to these two examples, one in RSS format and the other in
The key point of contention is the format of an
- . The rest of it is easy.
In RSS an
- can contain a
and a .
- can contain a
and a set of s. A contains a and a .
We agree on a common format for an
- s may optionally contain any of the following:
is a the title of the story. Usually the headline displayed at the top of the page containing the story.
is a URL, pointing to the story on the host website.
is a string of characters, containing HTML markup limited to and tags.
It's a compromise
We want to move beyond s. They were the best we could do when XML was kind of hazy in late 1997, and no one else cared about this stuff. There are significant problems with the approach we took. Now is a good time to unwind that little loop.
With this new format for
- s, people who wanted to produce channels for My.Netscape.Com could leave out the
part of the
- s. Netscape's server would probably not have to change at all, they would just ignore the
s. I couldn't be sure because I don't know how their XML parser works.
But we'd encourage channel developers to go ahead and include a lead paragraph with links, so that aggregators like My.UserLand.Com could display them. We hope Netscape would join us in this recommendation, but they wouldn't have to.
In A Faceoff With Netscape, 6/16/99, I said: "A channel is not a series of links pointing to articles, it's a set of paragraphs that point to one or more articles *per paragraph*."
As a content provider myself I feel quite strongly about this. If you look around the web at the news sites, you'll see that many of them agree. Each story, at the top-level, is a paragraph, allowing you to read a little to decide if you want to read more.
Netscape contends that this is a different application from the one that RSS supports. Maybe so! But I think with some creativity they don't have to be different applications.
Everything else is easy.
has a more extensive