I agree completely with the idea of “vendor neutrality” – one only has to point to the nervousness of the web development community after MS’s recent announcement of the abandonement of standalone IE to see what kind of havoc this can cause.
Anybody know the story of the person who developed ‘make’? He was going to change the format a few days after he released it so that it would make more sense, but was told that it was already out there and shouldn’t be changed.
— David 
Great idea! Assuming the New Format won’t become overly complex, this sounds like a good way out of the RSS carousel.
— Tomas
I’m still sitting on the fence on this one. Aside from political issues, is there anything wrong with RSS 2.0? I understand the motivations of the pie-Wiki movement, but I’m cautious about supporting yet another syndication format unless it really is unavoidable.
Simon: What’s wrong with it is its vendor dependence. While Dave Winer claims that “he does not own” RSS, he often *acts* like he does, which is just as bad, or worse.
— Tomas
I think characterizing RSS 1.0 as mordibund is unfair, its working, and working very well. RSS is a very very simple concept (despite claims to the contrary and attempts to make it so), the 1.0 spec got it just about perfect first go.
The other thing it did was create a lovely little XML format that is really the world first successful webservice, a pipeline which I can push all sorts of information across.
Amazingly it managed to be both simple, and flexible, and extensible. Wow.
I worry that a new format specifically for weblog syndication, one that conflates the data with the wire protocol will lose all of that.
— kellan
re: “Aside from political issues”. Heh. That’s a big aside.
And the answer is still yes. There are potential legal issues. UserLand Software once tried to trademark the term “RSS”. They later abandoned the process, but nobody even knew about it until years later. (And Dave never mentioned it at the time. In fact, I don’t know that he has ever publicly admitted it, although he privately admitted it when I posted the link in my “History of the RSS fork”.)
http://tarr.uspto.gov/servlet/tarr?regser=serial&entry=78025336
Vendor-owned specifications are bad. There are always hidden costs. No matter how good their intentions, vendors always seem to pop up and assert themselves, somehow, to the detriment of all. Last fall, we thought the addition of namespaces to the specification would make RSS 2.0 “good enough” in this regard (by allowing anyone to freely extend it), but it has obviously proven to be “not good enough”.
— Mark
I don’t really see what Real World Problems a new syndication format is supposed to solve, that can’t be solved with RSS 2.0, namespaces, some common-sense, and patience towards your fellow syndication geeks.
I’m positive that we can gently, and patiently move RSS 2.0 towards a more vendor-neutral ground. This time, instead of attempting to highjack the format (as with RSS 1.0) we should try to get Dave Winer and all the other blogging tool vendors on the same boat and officially move RSS into the hands of some sort of a neutral RSS consortium.
Hmm… maybe I’m just Not Getting It(tm)? :-|
I’d like to hear at least one important concrete technical problem with current solutions that can’t be reasonably fixed in the framework of RSS 2.0 that necessitates a new format. I understand that the format is not yet in place so you can’t give me a proposed solution, but I’ll settle for a problem.
If there’s a technical reason, then I’m at least neutral on this, and I speak as someone who will very likely be implementing this in the relatively near future.
If, however, this is strictly political and you have no real technical beef with RSS, then I am extremely unsympathetic to this. RSS isn’t controlled by Userland, as evidenced by the fact that all Userland can do about Dave’s complained “funkiness” in the MT feeds is, well, complain. Userland runs no certification process, can’t get a trademark on it now anyhow (very much a generic term now), extracts no licensing fees, and other then holding a copyright on the specification (with about as loose a restriction on it as you can get) I just don’t see Userland “in control” of RSS in the same way that, say, Microsoft controls the protocols Samba uses.
So I’ll hold off on judgement until you can answer whether there’s a technical reason for this, but I find the political goals extremely unconvicing.
Like I said, I understand the political issues – I was asking because I wanted to know if there were technical limitations of RSS 2.0 as well. It doesn’t appear that there are any technical limitations (thanks to namespaces allowing for extensions) so I’m going to sit this one out for the moment. I think my ideal solution would be for RSS to be taken under the wing of a standards organisation, although I know Dave Winer has opposed such moves in the past and as such it seems a pretty unlikely result.
As an RSS bystander, I strongly endorse the “new format” proposal, for the reasons Mark gives: it’s time to pour real-world experience into the data model and format decisions, the data model discussions seem to be converging, etc.
Whether anything is technically “wrong” with RSS 2.0 is a bit beside the point. It’s not rigorously defined (e.g, the “funky” nonsense), but it’s not evolveable, Probably “Son of RSS” will look a lot like it (except for the root element name, I hope and pray!). So sorry — “RSS” [all flavors!] as a label is contaminated by all the posturing, politicing, personality clashes, etc. etc. etc. See Tim Bray’s http://www.tbray.org/ongoing/When/200x/2003/06/19/RSS4All “Houston, We Have a Problem” comments.
Most importantly, “Son of RSS” needs to be a living, evolving spec maintained by an organization with some credibilty. That doesn’t mean it has to be a “real” standards organization, just that it’s a group that operates in the open, by consensus, and not dominated by any person, company, or ideology. Likewise, the spec itself has to be explicit enough so that someone other than the spec authors can determine whether an instance is in compliance or not.
I’d also encourage you to take a look at newer, out-of-the mainstream XML technologies such as RELAX NG, Schematron, and Examplatron that might offer a better combination of eas-of-use, power, rigor, and flexibility than DTDs or W3C Schemas.
— MIke Champion
Funny you should mention Samba.
http://www.samba.org/samba/ms_license.html
Vendors always end up asserting themselves, somehow. Even if there’s no basis for their assertions, it creates confusion in the marketplace, which works to their advantage. And yes, “funky RSS” *is* creating confusion in the marketplace. cf. http://philringnalda.com/blog/2003/06/say_it_loud_im_funky_and_im_proud.php
— Mark
The issue seems to me to be that Dave Winer has the power to create confusion in the marketplace. For example, see Adam Curry’s comments here:
http://www.blognewsnetwork.com/members/0000001/2003/06/23.html#a3949
“If I understand correctly, several blogtool vendors are making up their own versions of rss as they go along. Most of these new formats won’t work with my aggregator unless adaptations are made.”
That is simply incorrect. MT’s default RSS 2.0 feed will work with almost every aggregator. It may fail with Radio Userland, but note that Radio Userland is controlled by the guy who owns the competing format. Neutral aggregator developers support RSS 2.0 with dc:date.
There is a very clear line between Dave’s vague comments and Adam’s incorrect assumptions. Dave has not taken the time to correct Adam.
So while Dave does not control RSS 2.0, he has a fairly sizable degree of influence over it, and he is demonstrably willing to use that influence in order to exert a degree of control over how it’s used. Assuming you disagree with Dave, that represents sufficient reason to want to move to a new format.
— Bryant
So to be clear, and with no implied judgement either way at the moment, for you Mark (since I don’t expect you to speak for the other supporters), this is (at least almost) entirely a political issue?
(Again, at the moment I’m just a bystander, and in the near future probably a direct member of the “target audience” of this proposal, so I’m trying to make sure I understand what’s going on.)
I think the question Jeremy Bowers is asking is a very, very important, because if this is only based on politics, then I’m afraid we have very little hope of ever getting anywhere with this.
What we will have (*if* this is only based on silly politics) is another RSS 1.0 episode, were a small group of incredibly smart people create a new, super-cool XML syndication format, and the rest of the world continues to use RSS. :-)
Actually, Mr. Winer responded to Curry with this post:
http://backend.userland.com/2003/06/23#a291
Also, according to some
(http://movableblog.richarderiksson.com/asides/2003_06.php#asides000474)
this post was much longer and subsequently edited.
— Liz
Jeremy, I can’t answer for Mark, but I have some heavily technical gripes with the current specification:
1. pubDate. Enough has been said about ISO8601:2000 vs RFC 822 already.
2. No common way of representing excerpts and extended entries. Should one encode all entities and put them within <description>, and assume it’s parsed as html on the other side, should we instead use <content:encoded>, or should we use <xhtml:body>?
There is lots of other things I would like to see as well:
- A better way of uniquely identifying resources than by URL. Even if Cool URIs don’t change, not all URIs remain cool.
- Remove the need to expose e-mail addresses to show contact information for a user.
Sure: some of my gripes with RSS 2.0 can be solved by resorting to extensions, but herein also lies the problem: one *has* to resort to extensions. Extensions that may or may not be supported by User-Agents.
Then there is also interoperability: Currently, we have two incompatible specifications. One that may be technically robust, but generally confusing for users (remember that many of those who will use a syndication format like this are _not_ experts), and one that may be simple to understand, but lacking without a number of extensions.
The goal should be to have one format. One that is complete, yet simple.
(And yes: there are, as evidenced by this, and every other RSS discussion, political and personal issues)
— Arve
Bryant: what makes you think that MT default template for RSS 2.0 (or even RSS 1.0 for that matter) fails with Radio UserLand’s Aggregator?
Try it:
http://notabug.com/blankblog/index.xml
http://notabug.com/blankblog/index.rdf
— Sam Ruby
I see mentions of editing blogs. This isn’t just a reformulated RSS 2.0, it looks like a posting format as well. Is it two-way?
A neutral posting API *and* reading format would end many of the interop problems in the industry. As it stands today, there are more (and varied) posting APIs than RSS versions. Closing all those up with one generic solution would be a real boon to developers that would no longer have to write three different reading handlers and five different posting APIs. I’m totally behind this, if that’s the aim.
— Matt
Liz: incorrect. He deleted the post which *appeared* (note the past tense) at the URL I blogged. That URL now points to an error page, but the text in quotes is (or, was) from that deleted post, and *not* Dave’s response to Adam Curry.
— Richard
Matt asked about an editing format. Yes, that is part of the roadmap. Although no physical modeling has been done yet, it is my understanding from previous discussions that it could be as simple as taking the post as it would appear in a syndicated feed, (possibly) wrapping it in a header, and posting it (with HTTP POST) to the server. No XML-RPC. No SOAP.
Joe Gregorio’s existing Comment API works like this.
http://wellformedweb.org/story/9
The point of this (technically) would be to allow for more extensibility than any of the existing RPC-based editing APIs. The Blogger (1.0) API’s shortcomings are well-known. Even the Meta-Weblog API can’t handle multiple categories. I haven’t seen the Blogger (2.0) API yet.
— Mark
Sam: you know what they say about assumptions.
OK. So despite the fact that nobody has problems with MT’s default RSS 2.0 format, Dave is warning that aggregators may have trouble with it. The rest of my post stands.
Note that Dave has not corrected Adam about the core misunderstanding: namely, that these “funky” feeds won’t work with some aggregators.
And that’s about all the RSS effort I’m willing to expend today. Off to read wiki.
— Bryant
Richard:
My apologies.
— Liz
Re: editing format. The same spirit of the CommentAPI is to be found in the RESTLog API [1], also created by Joe Gregorio: you take an RSS item fragment and POST it as is on the server. Even if Joe recently said [2] that his RESTLog specification needs to be much better than it is in its actual state, I think it could be a good point where to start in the attempt of craft the (new?) API for the roadmap.
[1] http://wellformedweb.org/news/5
[2] http://bitworking.org/news/CommentAPI_POST_Return
Building something new is less destructive than harping endlessly about something old. Sounds cool. Lets do a Python implementation. Lets just agree on something and go.
They say you want a revolution, well you know…
— via con Dios
Mark said: «Even the Meta-Weblog API can’t handle multiple categories». From metaWeblog API spec:
» metaWeblog.getCategories (blogid, username, password) returns struct
» The struct returned contains one struct for each category, containing the following elements: description, htmlUrl and rssUrl.
» For categories, pass an array of strings of names of categories that the post belongs to».
Jeremy,
Is RSS 2.0 a dead format? As in, do you think it will never be changed? Dave Winer has made it perfectly clear that the thinks *he* is the one in charge of RSS, and anybody who dares to change RSS is *stealing* from him.
Perhaps people are just fed up of having to deal with him, fed up with his attitude, and fed up with the whole damn mess that is RSS.
A clean break will fix this. Even if Winer participates, it’s clear that he isn’t running the show. It will have a new name, and not require backwards compatibility, so the new format will be free to be better designed (e.g. pubdate issues), which may not constititute a big problem with the RSS 2.0 spec, but is just another one of those annoyances that accumulate.
— Jim
Provided the format is not unreasonably complex and it can be explained to a fairly competent computer user (allow me to consider myself to be one, please) in a fairly short amount of time, I’m all for it.
— Warren
Victor, my comment was in reference to this:
http://www.intertwingly.net/stories/2003/01/26/evolve.html
Specifically this section:
http://www.intertwingly.net/stories/2003/01/26/evolve.html#DuplicateNames
— Mark
Speaking of RSS, here’s my solution to: http://diveintomark.org/archives/2003/06/22/why_im_unsubscribing_from_your_blog.html
MikeyC RSS Parser: http://www.zeit.ca/dive.zip
“Easily segregates ‘Dive Into Mark’ topics to your liking!”
Its an HTA Application so its Windows only…yeah I’m a hack…
Also its meant to be funny so don’t take offense ;)
— MikeyC
MikeyC, have you seen my category-specific RSS feeds? I’ve had them for months.
— Mark
I’ll say more on my blog, but this is a good chance to make weblogs work better with the new generation of XML generation/editing tools based on XForms. -m
re: “Sam: you know what they say about assumptions.”
Um… they make an ass out of u and umptions?
— Kevin
Or, on second thought, mptions.
Or, on third thought, and after googling that joke, it’s not at all original, so never mind. Sorry.
— Kevin
“MikeyC, have you seen my category-specific RSS feeds? I’ve had them for months.”
Yes Mark, I have. It was just a pathetic attempt at humour.
— MikeyC
Why not revive RSS 1.0 and mold it to your needs for 1.5?
RDF isn’t that hard. Let’s face it, any one who dives into an API isn’t an average Joe who can’t grok RDF, especially in the limited use in RSS 1.0.
— James
I think Matt (http://diveintomark.org/archives/2003/06/23/a_fresh_start.html#c002581) is onto something: if this new format could be used as a standard weblog entry as well as a syndication standard, it would greatly simplify the development and interoperability of blogging tools, and that could be very cool. I don’t I’ve ever heard anyone claim such powers for any of the current syndication formats.
And if it was simple enough that you could create or edit entries by hand if need be, that would be even cooler.
— Arthur
One of the hard questions is whether a syndication format should carry the content or only references to the content. Lately, I’m been thinking I might prefer the latter provided that a subscription feature was integrated in my favorite browser. If the syndication format is to carry the content itself, there’s another hard question: “What should the format of the content be?”. RSS dodges these hard issues by underspecifying the format and the contents of the description element. Even though RSS is supposed to be Really Simple, allowing “entity encoded HTML” means any client that wishes to do something with the description element has to deal with tag soup–and dealing with tag soup is inherently not simple at all. The sad part is that most people use tag soup in – tag soup out content management systems, so for them generating “entity encoded” tag soup is really simple and generating something that would be easier to consume is hard.
At least a new specification should be specific about these things instead of just saying “entity encoded HTML is allowed”.
I think the main reason why the RSS 1.0 highjacking attempt “failed” like it did, was that it offended the sensibility of regular RSS publishers/users. The new format wasn’t compatible with the huge user-base that had already formed, and was too complex.
Having said that, I think there is no reason why a second highjacking attempt (this time done right) could not succeed.
I mean, RSS is a free format. Dave Winer and others may object, but the bottom line is that if the users (developers and publishers) are happy with the new development of a new revision of RSS – lets call it RSS 2.1 – then that is where RSS will go tomorrow.
All you need to do is to write a new RSS 2.0 spec (v.2.1) and post it to a neutral server. This rewrite should address the concerns with the current Spec: be more specific, formally solve the pubDate vs. dc:date issue, mandate ways to map native RSS elements to similar elements from common modules (DC, Syndication, etc.)
Create a formal RSS 2.1 website with loads of examples of “Best Practices” and test-cases for RSS Parser developers and RSS Publishers alike.
Stick to the old RSS is Really Simple Syndication, and I think everybody will be happy – Dave included – and the syndication world will have moved forward – this time for real.
This may sound like a completeyl stupid question, but I see nowhere in the Wiki or on the various blogs I’ve perused *where* the discussion is being held. is there a mailing list or something along those lines? or is it really beaing drafted in situ on the wiki?
In other owrds, How can one join in?
— Moof
The wiki is it.
During the “hey wouldn’t it be cool if…” phase, there was an ad-hoc mailing list (really just a long CC line) of a few people to gauge interest in a vendor-neutral format. It was quickly decided that we were all interested as long as Sam did all the hard work (like setting up the wiki), and then the “list” was quickly disbanded and it’s been wiki ever since. :)
If you don’t like wikis (and some don’t), feel free to post additional thoughts on your own site, and then link to it from the appropriate page on the wiki.
— Mark
I noticed the comments earlier about this effort forming what is a standard weblog entry. I don’t this effort is based on anything other than interoperability. To go beyond that risks infringing on how weblogging tools ‘work’, not how they interoperate. In addition, this could could even break into how people use the tools, rather than interoperability.
I think it’s important that a scope and focus is maintained on this effort, per original request for comment that Sam initiated way back when.
To me, and I know I’m repeating myself here, the key is interoperability, something we currently lack to a great extent. If there were a common interchange format, then migrating from one too to another would be a snap.
— xian
I would put “early” or “quick” or “easy” interoperability of current systems first, with using standardized web techniques a near second.
One reason I stress Dublin Core definitions, for example, is that they spent umpteen years working out definitions for interoperability *in this area*. A key distinction of Dublin Core is that it is layered. At the most conceptual are definitions; the definitions have names or labels, but the names or labels aren’t proscriptive, it’s “good enough” to say “my foo date is a dublin core creation date”. At the next layer are the dublin core terms, which can be reused as-is or refined by user created term. At the lowest layer are (just) guidelines for use in various serializations.
I’m working on saying that better, because I believe there’s a lot of people in our community who think Dublin Core is RDF.
Ken,
That is certainly the case. I know that when *I* first got into this area I was under that impression the DC was just an older version of RDF.
— joe