intertwingly

Guys, do we want to go there? Just because we can, should we?

Aaron posted a one-liner that parses it; maybe I'll integrate that into my parser. :)

I propose we call Aaron's format "Plain Text Syndication" (PTS), and create a new mime type "application/pts+plain".

Well, obviously if it's more than just a prank, it shouldn't be called RSS 3.0. Other than that, why not go there? Aaron is experimenting with a different syndication format. It solves some of the same problems as other formats, but obviously not all of them (the intentional lack of HTML, for example), and maybe it creates other problems. Are the tradeoffs worth it? Does it solve problems people have? Will it make it in the market?

I'll tell you this: it's certainly less bandwidth intensive than other popular syndication formats. I get over 5000 hits a day on my RSS feed, and I'm already over my bandwidth limit (which applies to all my sites combined, so it includes lots of things). So format bloat is a very real concern for me; I look at file sizes and see dollars and cents.

I can't see why this plain text format shouldn't be encouraged. From what I've seen of RSS [especially with talk of "liberal RSS parsers] it seems that it mainly uses XML for buzzword compliance and not much else.

OK, I should qualify that to mean the 0.9x flavors. Although I suspect the 0.9 and 1.0 versions are the same.

RSS 0.9x is /supposed/ to be well-formed XML. (The spec says so, in like the first paragraph.) RSS 1.0 is /supposed/ to be well-formed RDF, in a serialized form that is also well-formed XML.

The reality is much different. Thousands of feeds routinely have encoding errors, and virtually no aggregators require well-formed XML. (None require proper RDF.) Although there is a move with some aggregators to display some sort of icon if a feed is well-formed, which I think would be a useful (and subtle) push towards standards compliance.

However, the vision of RSS 1.0 -- that computers would all get together and aggregate feeds and extract semantically useful information from them via RDF manipulation -- has not materialized. By far, the main consumers of RSS are people who just want to read cool stuff, and they don't care what it looks like going over the wire.

I agree with Dare and Mark. Simplification isn't necessarily a bad thing. Take this exchange via email that I received unsolicited from someone working for the RDF folks who shall remain nameless. Note: this is not an indictment of this individual.

ME:

| Thank you. Perhaps I am mis-labeling the RDF 1.0 feed. Would
| it be more
| correct if it was labeled RSS 1.0 or is that still wrong? I use the
| movable type templates unchanged to generate those feeds so anything
| that I change would theoretically need to change in their templates:
| http://www.movabletype.org/default_templates.shtml

RDF REP:

No, it wouldn't be correct. I was looking at the templates, and they're
wrong. I'll talk with the people of MovableType later. Right now I'll
try to help you...

======================================

He then went on to explain a bunch of very granular changes that needed to be made to my RSS or RDF or whatever you want to call it. Those changes were fairly hideous since the generation's being done by a template. I didn't follow through with the changes and luckily so because a few days later I received more mail from him explaining that he forgot some things and yet more ugly code changes. Finally, I received a third mail explaining more changes and telling me to wait for more. At this point I concluded that the RDF validation effort that these people were valiantly undertaking was doomed.

This left me concluding that the user experience with these syndication standards, even with the assistance of supposed experts, is not good. The last time I checked, the MT templates had not changed from what I have installed. Given the installed base of the blogging tools, it sure seems like the #1 priority of any validation effort should be to get the tools to comply, not the users.

I guess what we're seeing here is a case of conflicting design goals as Mark suggests, ie. designing for the semantic parser vs. the poor weblog user trying to grok the stuff. Perhaps those design goals are best served by separate approaches?


Posted by David Watson

Here is a cut/paste of a note I sent to Dave Winer yesterday. I think it lines up with and adds something to the sceptical aspects of this comment-thread.

//*
Dave,

I watch the RSS exchanges with facination and chagrin. On the one hand, the promise of RSS is palpable and manifest in Radio Userland and the many, many other blog publishing tools.

On the other hand, it's troublesome to contemplate the history of RSS. In particular the early era, during the browser wars, when Nestcape had a glimmering and soon extinguished vision of RSS promise.

What I take away from all this is the following notions:
1. the ability to do something doesn't mean it should be done.
2. the ability to do something doesn't mean anyone will be interested in doing it.
3. the ability to do something requires, on an ethical plane, the concomitant capability for everyone to *not* do (all of) it.

I think points 1 and 2 are pretty self-explanatory and have been done to death elsewhere.

What I mean by point 3 is that developers, visionaries and business people, such as you, need to think very seriously about what "hath been wrought" by your technologies. In the case of RSS, there is the potential for a level of intrusiveness and annoyance similar to and perhaps more virulent than that of email + spam.

As an example, there are capabilities in RSS, as I understand it, for sending images and markup through a feed. This is a capability far beyond the basic "who, what, where and when" functionality of a simple RSS feed. It is similar, in my mind, to a Web developer's being able to open and brower window without the user's permission.

As a specific example, I don't like receiving images via your RSS feed, particularly repeated images that have no context or meaning to me. I want the ability to turn off images and the items that contain nothing but images, turn off html, turn off anything that I don't want to see or know, about an RSS feed.

It's fine and good to talk about "optional" from the point of view of a developer. There needs to be an equivalent discussion about what the subscriber can find optional, as well. And a demonstrated level of good faith in the discussion that shows an appropriate sense of responsibility in the face of new capabilities.

Please keep these thoughts in mind, take them seriously and do whatever you can in your leadership role to minimize the frustration of countless users, down the road, when the hucksters, marketers and genuinely sleezy of the Net get the "new and improved" powers of RSS in their grubby little hands.

Regards. ...edN

I gotta agree with Dare. "RSS 3.0" may be a brilliant parody or a real suggestion, I don't know. But XML is just a convention for labelled (i.e. "self describing") data, and the only reason to use it rather than something like RSS 3.0 is to leverage other people's parsers, validations, display tools, etc. If RSS folks are rolling their own anyway, and not rejecting invalid or even ill-formed "XML", why bother?

For that matter, all this syntax can be parsed into XML infosets, and THEN someone can use XSLT, CSS, DOM programs, schema validators, (with a little work) RDF inferencing ... If you've given up on syntax-level interoperability (as RSS aggregators did long ago), what advantage does XML syntax bring at all?

I nearly wrote a spec for RSS 7.0, that would make RSS take the CSV route !

But then, I cried.

I think RSS 3.0 is more like a protest agains "RSS madness" not really a standart. That's way I done my site "TXT syndicatable" and will stay with RSS 0.92 and "RSS 3.0" until it is possible.

Sam Ruby picks up the story of the discord in the RSS community by implementing ESF on his site. If... [more]

Trackback from www.davidwatson.org

More of the same.... [more]

Trackback from dive into mark

(SOURCE:"diveintomark")- RDF mass use may happen someday but it looks like we need one or more of the following: a) a better RDF standard b) a better RSS with RDF standard c) better tutorials on RDF d) a killer RDF app -- Unfortunately, sarcastic (no... [more]

Trackback from Roland Tanglao's Weblog