| August 2002 | ||||||
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| Jul Sep | ||||||
This site is no longer maintained.
My current weblog.
Saturday, August 31, 2002Semantic Differences
To bitch some more... The ambiguity over LINK elements stems from changes introduced in the RSS 0.92 spec. With the RSS 0.91 spec, ITEMs were clearly intended to summarize content. The DESCRIPTION element was a synopsis of the content, with a maximum length of 500 characters. The LINK element was required and supposed to point to the full content.
With RSS 0.92, the length limitations are gone, LINKs are optional, and with Userland's RSS implementations, complete content is syndicated instead of summaries (initially without LINKs, later with ambiguous LINKs).
RSS 0.94 ought to address the disconnect created between the two previous specs and remove the ambiguities. Also, why are LINK and URL elements suddenly restricted to HTTP and FTP? HTTPS may be required for corporate applications of RSS and k-logs, but more importantly, there are many Official URI Schemes and not all uses of RSS center around Websites and Aggregators. Applications should decide how to handle unfamiliar or potentially dangerous URIs.
I'd also like to see the word story replaced with item or syndicated content, but that's just nit-picking.
New version of RSS found lacking
As promised, here's the first draft of the RSS 0.94 spec. It's a consolidation of all the specs I've written over the last two years. A few new features, listed on the (new) change notes page. Please read the roadmap to see what comes after 0.94. I'm not looking for much feedback until next week, but of course if you like it, no need to wait to say that. [Scripting News]
It's disappointing that Userland hasn't taken this opportunity to clarify the use of an ITEM's LINK element. The spec describes it as "the URL of the story", which many have interpreted as "the URL of the content in the DESCRIPTION element" (Permalink in weblog-speak). Radio, however, doesn't generate LINK elements by default and allows the user to specify an arbitrary URL (presumably to content referenced by the story).
This has been a source of contention amongst Aggregator developers, see Radio Userland Feeds Found Lacking and the resulting discussion.
Rather than address the confusion, RSS 0.94 had added a GUID element (Globally Unique IDentifier) to enable Aggregators to determine if an ITEM is new. The content of the GUID is unspecified, which will lead to more confusion. Userland's present implementation uses a Permalink for the GUID, which is probably the only way to ensure global uniqueness under these circumstances, but the reality is that Aggregators will have to assume that the GUID element will only be unique to an individual feed.
Now, the fact that GUIDs and LINKs within an ITEM contain ambiguous content is a Pain In The Ass for Webloggers that use Aggregators (ie: most Radio users). When weblogging about external content, it is proper form to include a hyperlink that points directly to the content in question (call it a citation, attribution, whatever). This should be automatic, but Radio's RSS feeds are ambiguous and Radio's Aggregator ignores LINKs.
