[reposted from Sam Ruby's weblog]
Mark,
We obviously have different opinions about syndication. From the discussion so far, anything I can do with an Echo/Pie/whatever syndication format I’ll be able to do in RSS 2.0. I don’t see much difference between the core Sam described at http://www.intertwingly.net/blog/1499.html and RSS 2.0 except that now for some of the things I’d like to do with "virtual RSS feeds" such as provide a view of my Windows EventLog or an NTFS file share that I can display in my news aggregator I have to generate irrelevant or redundant information such as having both link and id or coming up with an author.
The only thing that is of interest to me is a unified posting API. However if this is going to work somebody is going to have to make it a spec (no one in his right mind is going to code against the descriptions in a Wiki) in which case I’d like to know if the person currently managing this project considers this a high priority or is simply making [sure] there exists a well-defined syndication format the main priority.
This question is for Sam not anyone else. If I didn’t feel that this is something that others would also find interesting I’d have just sent him an email.
“I want to do all sorts of fancy things that RSS doesn’t allow for.”
Like what?
The reason why RSS has done so well, and why a big corporation like the BBC and a small website like mine still use RSS 0.9x is because it’s so simple. Headlines and links.
Do we want non-ASCII things in there? Isn’t that what a web-browser is for?
This was all so simple once….
Two points:
1) Great post Mark. I’ve disaggreed with your previous posts on the subject (they were needlessly spiteful IMO), but I think you’re spot on with this one. The true forward motion only happens when people start to leave RSS alone.
Also, support for Echo and RSS are needs not be mutually exclusive. You/we should continue to produce, simple, un-Funky RSS 2.0 even after the Echo format gets off the ground, because RSS is good at being what it is – a somewhat sloppy, but kind of useful syndication file format. :-)
2) Dare: I think your concerns (posted here and on Sam’s weblog) are very, very valid.
RSS surely can do with some more work, but even without that extra work, RSS is “Good Enough” syndication format. Thus, the Echo project needs to focus on solving Real World Problems that are different from the problems that RSS solves “Well Enough” today.
This whole arguement works for me.
Leave RSS alone, work on the new project.
RSS works and has worked for some time, it has the support, but the project-once-known-as-Echo has advantages and can be used in many ways.
The most interesting form for me is a standardized entry format for interaction with different systems, importing and exporting data, as XML is supposed to be used.
Dare sez: “…some of the things I’d like to do with “virtual RSS feeds” such as provide a view of my Windows EventLog or an NTFS file share that I can display in my news aggregator…”
Okay, fine. Continue using RSS for those applications. That’s not what [not]-Echo is designed for. Echo is being designed specifically for handling the type of content that one typically finds on a weblog or other article-oriented site. It’s not being designed for exporting filesystem information.
Just use the tool appropiate to the job you are trying to accomplish.
— Dougal 
It would be nice to get a list of the power
user features that will be supported, with some
kind of detail that makes you say aha. Having
to send redundant information isn’t sufficient
reason for a change. Unless echo is perfect,
it will also grow some cruftiness.
— Anonymous
bummer, I liked getting the whole article in your RSS feed.
— Anonymous
It’s fine conceptually that you’ve switched to GUID from LINK for permalinks, but there’s an implementation caveat: At least in NetNewsWire, your entries no longer have links.
This is kind of a pain, and appears to defy the entire purpose of an RSS feed.
Is it really not permissible on some level to provide both, for those of us who can’t see the links?
http://scriptingnews.userland.com/2003/06/25#theLizardBrainOfRss
“Now that [guid] does exist, I really feel strongly that people should use it, and let link be pure.”
So, no. As of June 25, 2003 (and apparently since forever, but it was clarified on June 25, 2003), [guid] is how you do permalinks in RSS 2.0. [link] is for the first external link referenced within the post. And since I have no way in MT to extract individual links referenced within my post, I have omitted [link] altogether.
Guids for everyone! Leave RSS alone!
— Mark
In response to this trackback:
http://blog.lordsutch.com/?entryid=546
content:encoded was removed because it duplicates the function of the core [description] element, which (according to the RSS 2.0 spec) explicitly allows for full posts (escaped HTML). However, as I mentioned in my post, I have two pieces of information: a hand-written summary, and the full post. [description] can only hold one of these, so I had to choose, and I chose the hand-written summary.
This is more in line with the original intention of RSS (as a summary format); in fact, prior to RSS 0.92, [description] was presumed to be plain text, and was limited to a certain length (I believe 500 characters).
The minute the physical modeling for (not-)Echo is complete, I will publish a feed in that format. The last time I checked, there is a provision for both a plain-text summary, and a full post.
http://www.intertwingly.net/wiki/pie/EchoExample
— Mark
Mark: Should you be looking outside the spec for guidance on how to use LINK and GUID? Dropping LINK entirely when so many aggregators associate it with TITLE and present it atop an item seems less than ideal, and there’s nothing in the spec that says if GUID exists LINK should be dropped.
“And since I have no way in MT to extract individual links referenced within my post…”
You could do this with the Collect plugin. (Also, you’re mentioned in the documentation…)
http://www.staggernation.com/mtplugins/CollectReadMe.html
— Kevin
I want namespaced elements in RSS because there are things I want to put in RSS feeds – educational purpose, for example – that are not defined in RSS.
It seems to me that if an RSS reader doesn’t want to deal with those elements, it could just ignore them, the way a browser ignores a tag it doesn’t recognize.
I like to use RSS for this purpose because it’s simple, widely used, easily parsed, and can be created by anyone with a text editor and a website. No specialized software, no user accounts: put some tags on a web accessible page, and you’re in the game.
As an aggregator, honestly, it doesn’t matter whether they’re two or twenty formats. So long as they’re in XML, I can parse, translate as required, pick and choose among tags, and store the data.
In the educational field, it is necessary to harvest both RSS and OAI, two formats that will never come together. That’s no problem: that’s the way the world is.
It’s the old rule: feed providers should be as compliant as they can be, with the understanding that as they become less compliant, they become less widely accessed. And aggregators should be as tolerant as they can be, with the understanding that if a feed becomes too much trouble, they can stop harvesting.
People preach standards as though they were a mantra, and it is true that we need common languages and formats in order to communicate. But we don’t all need to communicate with each other: and the way forward is not a single standard, but a plurality of standards, some overlapping, some not, eacher chosen by its producers and its readers for their own needs.
“The most interesting form for me is a standardized entry format for interaction with different systems, importing and exporting data, as XML is supposed to be used.”
+1
— xian
Rogers, as Fredrik has eloquently argued elsewhere,
http://www.intertwingly.net/blog/1503.html#c1057042800
one must look not only at the spec but at the history that has built up before and after it. Dave has been very clear
http://blogs.law.harvard.edu/bloggingFormatsProtocolsMay2003
that everyone should do RSS exactly as UserLand does. He repeated this statement just yesterday
http://backend.userland.com/davesRss2PoliticalFaq
His recent clarification on [guid]
http://scriptingnews.userland.com/2003/06/25#theLizardBrainOfRss
was very clear. UserLand tools (Radio and Manila) do not, by default, produce [link] at all; they use [guid] to express permalinks, and [link] to express external links. Manila has an entire “News Item” mode centered around this style of posting. I believe Wesley Felter uses it.
http://wmf.editthispage.com/
http://wmf.editthispage.com/xml/rss.xml
But that is not the style of posting that I’m doing. I post long essays of original content, so using [guid] to point to the permalink of each essay on my own server is the best choice.
Don’t abuse [link]! Leave RSS alone!
— Mark
To second what Kevin said, I use the plugin on ThirdSuperpower.com to build the list of links in each entry. I would post the code but Mark’s sanitize routine just strips it right out.
So, could this be used to put multiple links in? Without trying to be funny, “link should be used only to link to the article being described by the post” is a little ambiguous when there is more than one link involved. I think you can pick something other than the first link, but I am not sure how I would indicate that to the template generating the RSS.
— Anonymous
RSS has *always* been limited to one [link] per item. Multiple links per item are not allowed. This is not mentioned in the spec; for clarification, you’ll need to go all the way back to 1999:
http://davenet.userland.com/1999/06/16/aFaceOffWithNetscape
At the time, multiple links per item was a key feature of Dave’s competing syndication format (called scriptingNews format). But when RSS 0.91 came out, it was “good enough”, and Dave adopted it and stopped developing his competing format. Dropping support for multiple links per item was one of the compromises Dave made at the time.
I believe he mentioned this recently on Sam’s site, but I can’t find the reference. Someone correct me if I’m wrong here.
— Mark
Found it:
http://www.intertwingly.net/blog/1494.html#c1056580532
Dave: “At the end the only thing scriptingNews format had over RSS 0.91 was the ability to have multiple links per post. It was worth compromising to have one format instead of two.”
So there you have it. No multiple links per item in RSS.
But now that you mention it, a complete list of outgoing links would make for a great (not-)Echo extension module…
— Mark
This for me hilights the problem with the RSS 2.0 spec/format.
One of the key ideas behind RSS 1.0, and seemingly behind Echo (though I’m getting less clear on the intent of Echo everyday) was the idea of a neutral spec.
Now from a neutral specification you have the right to expect 2 things.
1. If you build software to follow the specification, your software will work.
2. There is a community of people involved which keep the spec moving in a productive conservative direction.
Dave Winer’s ability to re-declare the meaning of ‘link’, fundamentally altering the core RSS datastructure, and breaking semantic compatibility with the RSS 0.9/RSS 1.0 branch of development is a key indication that RSS 2.0 is not that neutral specification. Clearly Dave feels like he owns the Userland branch of RSS, and can do with it what he will. Fine for his own internal Userland format, but disingenuous for something that claims to be an open standard.
Also, Mark, people are confused enough about what is going on with RSS. While I totally support your right to do whatever you want with your feed aesthetically, wording your choice in just those terms, a personal choice within the bounds of standard, would help avoid adding to the already hysterical tone of late.
— kellan
kellan: Dave did not “redefine” [link], he simply clarified it after 4 years of widespread confusion and mis-implementation.
Also, RSS 2.0 is not an open standard; it is not a standard at all.
http://scriptingnews.userland.com/stories/storyReader$1744#theSoapOfSyndication
Dave: “I cringe when people call [RSS] a standard. I know how it was developed. It’s a format, not a standard.”
Finally, Dave does not control RSS. He influences it.
http://backend.userland.com/davesRss2PoliticalFaq#questionButIReallyMeantDoYouControlTheUseOfRss
Dave: “Basically, I have the power, like anyone else, to say what I think, but I can’t make people do what I think they should.”
An analogy: what I’ve done today, with my feeds, is what Dave thinks should be done with RSS. The roadmap I’ve outlined for (not-)Echo is what Dave thinks should be done with RSS (namely, leave it alone). So clearly Dave has influence over my decisions, but he doesn’t control me. ;) I choose to make these decisions, and if he agrees with them, and that’s great. Maybe next week I’ll make a decision that he disagrees with. Oh well!
— Mark
I test software for a living. I can’t tell you how often a bug report goes like this:
ME: Feature x is broken.
THEM: No it’s not.
ME: The requirements say that feature x should do this, but instead it does that.
THEM: Weren’t you invited to that meeting a few days ago where we changed that? You can’t follow the requirements; they’re not worded correctly. The requirements say this, but we actually *meant* that.
ME: Could you update the requirements to be more specific? I can’t do my job without a reliable reference for determining the software’s correct behavior. Besides, now all of my work from the past week is invalid.
THEM: That’s a shame.
[A month passes.]
SOMEBODY ELSE: Feature x is broken. Why didn’t you catch that?
ME: It’s not broken. The requirements say that feature x should behave like that but what they really mean is that feature x should behave like this.
SOMEBODY ELSE: All I have is this requirements document. It says that feature x does this.
ME: Weren’t you at that meeting where we, um, clarified that to mean something completely different?
SOMEBODY ELSE: No. Make feature x do this instead of doing that.
ME: Excuse me, I need a cigarette.
— jacob
Mark, that’s what I figured your reasoning was at the time (when there’s a potential for funkiness – avoid it!). But the post was (a) already getting longwinded and (b) doesn’t detract from my general point: the ability to encapsulate both markup and plain text in a feed is at the core of what weblog syndication is about, and RSS 2.x (as specified) doesn’t clearly provide for that.
Chris: agreed. In fact, your point is even stronger than that. RSS 2.0 (as-is) does not provide for that at all. You get one [description] element per [item]; you can use it for a plain-text summary (like the original versions of RSS), or you can use it for full content (added to the specification in 0.92). But you can’t do both.
(not-)Echo core will provide a well-defined way of doing both.
— Mark
This leave RSS 2.0 alone is all well and good, but switching your permalinks to guid tags instead of links broke my simple aggregator and it doesn’t allow anyone using my MT plugin to link with your feed or any others that follow your lead.
I suppose backward compatability and disconuties are irrevelent?
Mark I’m missing the significance of the difference between “standard” and “format” in this case. Care to elucidate? I understand its not an IETF standard, or an ISO standard or some such, but RSS has been positioned as an open format for interoperability, and have gained popularity on the back of that idea. To me that distinguishes it from when Microsoft tweaks the saved document format of Word.
I also fail to see how a clarification is different then re-defining. I think he is wrong about what link means and if RSS was an open format (trying to avoid that word standard) there would be room to dicuss it. But it isn’t, Dave controls it, despite what he might have said on his webpage.
And for all the talk about the “reckless” behaviour of Echo, discarding 1 or the 2 core elements (title and link and later description) is an amazingly reckless act. Up until that point all versions of RSS 0.9-2.0 (I’m not sure about the 3.0+ series) shared those basic elements and could be parsed agnostically.
— kellan
Timothy: you’re addressing your concerns to the wrong person. I didn’t write the RSS spec, nor did I clarify it.
kellan: you’re asking your questions to the wrong person. I didn’t make those statements; I’m merely telling you what the spec author has stated publicly about the matter. He says RSS is not a standard; he says he doesn’t control it; he says [link] –> [guid] was not a redefinition.
Naturally, you are free to have a different opinion. Whatever. RSS no longer concerns me. I’m finally doing RSS 2.0 the way the spec author intended, so now I’m turning my attention to other things.
— Mark
UserLand tools (Radio and Manila) do not, by default, produce [link] at all; they use [guid] to express permalinks, and [link] to express external links.
Actually, if you leave the Link field blank in Radio, it puts the entry’s permalink in both the LINK and GUID elements, as shown in my RSS 2.0 feed. So in spite of what Dave would like to see, at present Radio supports the duplication of LINK and GUID that I’m suggesting here.
Clearly Dave feels like he owns the Userland branch of RSS, and can do with it what he will.
UserLand owns the RSS 2.0 specification and disclaims any ownership of the format it describes. We’re demonstrating this point now on SSF-DEV by writing a new spec.
Mark, Thanks for the clarification on the point about multiple links. I had read that earlier but it is getting hard to keep all the various threads of conversation straight. I guess this makes the point that RSS is really simple. As Moss said at the time, it works much better with the classic weblog than it does for most of us today. And judging from the other comments, this should give an incentive to the (not-)Echo movement to come up a format to replace your defunked RSS.
— Michael
Paragraphs 1 and 3 of my comment are quoting Kellen. Apologies for the confusion — I obviously missed the “no HTML” part of this comment form. Which could use a spec.
Rogers: the comment form clearly states “no HTML, auto-linked URLs”. You can escape it manually, or use square brackets.
— Mark
Roger your paragraph 1 isn’t found in any comment of mine, not sure what you mean there.
As for ownership, let me clarify. What I said was, “Dave feels like he owns RSS”. He feels ownership over it. When you feel ownership of something you try to protect it which is a good thing, you also feel like you can change it to suit your needs. (depending on your degree of civic mindedness) I don’t think *anyone* believe that Dave owns the RSS 2.0 format in sort of patent/copyrighted manner. (though the Userland attempt to copyright [or was it trademark] RSS does make you wonder).
Roger as for your project, my understanding is all you got blessings from Dave to do was rewrite his word.
— kellan
Mark,
It occurs to me that if you are putting the summary into the description element, then, from the POV of the RSS feed, you are describing the full article – and so there is no meaningful permalink, but the link element would be appropriate to link to your full article.
Is anybody else reading the spec the same way as me?
— Jim
Rogers: it appears you are correct and I am wrong about Radio’s default behavior. I believe Dave was implying here
http://scriptingnews.userland.com/2003/06/25#theLizardBrainOfRss
that Radio’s behavior should be considered incorrect. (Although now that I re-read it, this is not entirely clear.)
However, I am correct about Manila’s default behavior, and this is what I was basing my statement on. Frontier 9.0 (and therefore Manila) uses [link] *exclusively* for the first external link in the post, and [guid] *exclusively* for permalinks. Example:
http://thebase.weblogger.com/xml/rss.xml
— Mark
Mark: “But now that you mention it, a complete list of outgoing links would make for a great (not-)Echo extension module…”
I started playing with that in RSS a month or two ago. All my entries produce a secondary feed that contains nothing but the links and descriptions from that entry:
original entry:
http://journurl.com/support/users/admin/index.cfm/mode/article/entry/561
link feed:
http://journurl.com/support/index.cfm?fa=links&m=561
As a subscriber to your RSS feed I have to say I preferred your old ‘out-of-spec funked to the max’ feed with the complete post, [link] and/or [guid]. I don’t five a guck. I like my [link] dirty, soiled, downright slutty.
If you poll your readers I’m sure they would like an option, RSS 2.0f or RSS 2.0u?
This is supposed to be about (your) writing, (your) readers and interaction — or lack thereof. In a way, you’ve penalised your readers/subscribers because of this debacle and it’s a shame. I’m sure Mr. Winer would prefer options to exclusion. Why should you be forced to comply via consensus terrorism and we get the short end of the stick [that's not meant to be a clever pun].
— Gummi
Sorry about the misattribution, kellan.
SSF-DEV neither sought, nor needed, anyone’s blessing to work on a new RSS 2.0 specification.
Does Dave have the capability to significantly help or hinder the project? Sure — he’s the leading proponent of RSS 2.0, the author and owner of the spec, an influential RSS software producer, and the best-known evangelist of the format. On a pragmatic level, I hope that SSF-DEV produces something that he can endorse and support.
But that’s not ownership — as evidenced by the release of RSS 1.0.
Well, RSS is not the last thing, but by going away from the Semantic Web effort, we are not going to win anything. RSS is a simple form of RSS, so maybe RDF should be the way to go along with a simple, RESTful interface.
— JJ
Gummi: to be very clear about this, I am in no way being forced to comply. I firmly and honestly believe that I am doing RSS the way that the spec intends, and I am voluntarily choosing to follow these intentions. (In places where the spec is unclear, I have dug up supporting evidence elsewhere from the spec author about his intentions.) I am now done with RSS — it’s frozen and I’m using it correctly — and I’m now turning my attention to other matters.
— Mark
Congratulations on making your blog less likely to be read. I tend not to follow excerpts through to the blog, and I think a lot of other aggregator users do the same. So if your goal was to be read less, you have succeeded. If not, you might ponder what it was you did have in mind.
I’m with Gummi: this is the platypuses all over again, with Mark’s humble readers being forced to suffer so Mark can make a political point.
Could not the same point — which appears to be “Dave Winer’s clarifications have made RSS 2.0 less functional in current aggregators” — be made just as clearly by:
a) coming out and _saying_ so directly, and
b) publishing a “strict” RSS 2.0 feed alongside the previous “funky” feed so that direct comparisons can be made?
Sorry, Mark, but you’ve cut off _my_ nose to spite _his_ face: your feed is now unusable (summary only, no link to full item) in Syndirella. I shall be unsubscribing and dropping back to occasional browser-based visits.
— James Kew
Re: “your feed is now unusable in Syndirella.”
Then Syndirella does not properly support RSS 2.0. It’s the job of aggregator developers to keep up with this kind of thing. [guid] has been part of RSS 2.0 since last September.
— Mark
Mark, when you write that you’re turning to other matter, that’s terrific. But wouldn’t you be doing more good for the actual users of your ‘product’ (and this is at your discretion) to make the change in your feed when nonEcho is actually available and the now-missing functionality available through that channel? Rather than just making a late in the game decision which benefits no one that I can really see.
Bill: it benefits the community at large if RSS is implemented properly and consistently by all producers. cf
http://blogs.law.harvard.edu/bloggingFormatsProtocolsMay2003
— Mark
You say:
“Re: “your feed is now unusable in Syndirella.” Then Syndirella does not properly support RSS 2.0. It’s the job of aggregator developers to keep up with this kind of thing. [guid] has been part of RSS 2.0 since last September.”
that’s all well and good, but it’s your readers that get hosed, and your readers who will drop your feed. I think you have forgotten the point. A lot.
I’m starting to appreciate Mark Pilgrim’s penchant for doing provocative things in his RSS feed to make a point as theatrically as possible.
However, it’s a bit of dirty pool to claim to be implementing “proper” RSS 2.0 by dropping LINK entirely in favor of GUID. As I think I’m demonstrating here, there’s nothing in any RSS 0.9x/2.0 spec that says LINK should be dropped if GUID exists.
Rogers: but that’s the way Frontier does it.
— Mark
Why does that matter? Frontier’s not a reference implementation of RSS 2.0.
If the RSS 2.0 spec (along with its scattered external clarifications) is a good spec in its current form, then Mark’s actions shouldn’t be causing any anguish. All he did today was publish his feed strictly according to spec. If that’s causing problems, then I would assume that the RSS 2.0 spec suffers from one of the following two issues:
1) The RSS 2.0 spec is too ambiguously written, and consumers (aggregators) of RSS 2.0 feeds are consequently faulty in their implementations because it is too difficult to interpret the spec consistently.
2) The design of the RSS 2.0 format is lacking in some way, and writing an RSS 2.0 feed to spec results in an unusable feed that doesn’t provide the information that people want and/or need, regardless of how the feed is consumed.
If that is indeed Mark’s point, then yeah, I see why Echo is a good thing.
(As an aside, I hope the XML-RPC/SOAP analogy turns out to be a loose analogy. XML-RPC, while limited, is much easier for my simple mind to digest than SOAP.)
— jacob
Rogers: And as Dave said here
http://scriptingnews.userland.com/2003/06/25#theLizardBrainOfRss
“”"
link should be used only to link to the article being described by the post, it should only be used in the TLD context. I believe that was a very solid application and shouldn’t be muddied.
…
Now that said, Radio uses link the way Simon uses it. But then guid didn’t exist when Radio shipped. Now that it does exist, I really feel strongly that people should use it, and let link be pure.
“”"
Frontier’s usage (and mine) is in line with this clarification. If Radio’s usage is not, perhaps Radio could be updated to bring it in line with this clarification. Or not. Doesn’t matter to me either way; I don’t use Radio.
Let link be pure! Leave RSS alone!
— Mark
Rogers: “As I think I’m demonstrating here, there’s nothing in any RSS 0.9x/2.0 spec that says LINK should be dropped if GUID exists.”
That’s true, but. The unadorned spec states that A) it’s safe to omit link if an item is “complete in itself” (i.e., a standalone story as opposed to a pointer to an external story), and B) everything is optional besides title and description anyway:
“An item may also be complete in itself, if so, the description contains the text (entity-encoded HTML is allowed), and the link and title may be omitted. All elements of an item are optional, however at least one of title or description must be present.”
— jacob
I’ve never thought of it as a bother to visit someone’s website in order to read their content.
I also never thought that the point of publishing a personal weblog was to be read by as many people as possible (but I suppose that depends on the person). I reckon my site would be full of pr0n if that were the case.
As a programmer, I think adhering to the details of the RSS 2.0 specification is a good thing… and you can’t go wrong following the best practices recommendations of its creator, either.
I introduced a bit of funk into my own feed recently, by using xhtml:body for the full content of posts but, once I get around to writing manual excerpts, I’ll probably drop it as well.
— Marcus
Re: “I reckon my site would be full of pr0n…”
You should subscribe to “Dive Into Premium”.
http://diveintomark.org/premium/
— Mark
Jacob: Point 1 is probably closer to the truth than Point 2, but from what I have determined, there’s nothing faulty in aggregators that pair LINK and TITLE prominently as a hyperlink atop posts.
I meant to link to my SSF-DEV post on the history and usage of LINK and GUID here:
http://groups.yahoo.com/group/ssf-dev/message/8
The purpose and usage of LINK has always been loosely defined. When permanent links became popular, RSS producers began putting their permalinks there for presentational reasons — most RSS consumers play up the LINK and TITLE more than the description — not because any spec decreed that the permalink belonged there.
There’s nothing off-spec about dropping LINK and using GUID; LINK is an optional element. However, there’s also nothing off-spec about using LINK and GUID both for a permanent link. Any interpretation that this is invalid, funky, or non-standard behavior isn’t reflected in any RSS 0.9x/2.0 spec.
From http://backend.userland.com/rss :
…
Element Description Example
link The URL of the item. http://www.nytimes.com/2002/09/07/movies/07FEST.html
guid A string that uniquely
identifies the item. [More] <guid isPermaLink=”true”>http://inessential.com/2002/09/01.php#a2</guid>
…
<guid> is an optional sub-element of <item>.
guid stands for globally unique identifier. It’s a string that uniquely identifies the item. When present, an aggregator may choose to use this string to determine if an item is new.
<guid>http://some.server.com/weblogItem3207</guid>
There are no rules for the syntax of a guid. Aggregators must view them as a string. It’s up to the source of the feed to establish the uniqueness of the string.
…
A frequently asked question about <guid>s is how do they compare to <link>s. Aren’t they the same thing? Yes, in some content systems, and no in others. In some systems, <link> is a permalink to a weblog item. However, in other systems, each <item> is a synopsis of a longer article, <link> points to the article, and <guid> is the permalink to the weblog entry. In all cases, it’s recommended that you provide the guid, and if possible make it a permalink. This enables aggregators to not repeat items, even if there have been editing changes.
Sure sounds to me like the RSS 2.0 Spec says that <link>: is a permalink to the weblog item, while <guid> may (maybe even should) be a permalink, but need not be.
Dave’s recent “clarifications” notwithstanding, using <link>: as a permalink is not only in accord with the Spec, but adheres to one of his guiding principles behind the design of RSS 2.0: namely that it should be “backwards compatible” with 0.91. RSS 0.91 used <link>: as a permalink. Ergo, RSS 2.0 must allow the same behaviour.
So Dave has decided to break backwards compatibility. If anyone else had tried to do that, he would scream bloody murder…
Jacques: RSS 0.91, from July 1999, predates the concept of permanent links and most of the use of RSS as a weblog syndication format.
No one was restricting the use of LINK to “permanent links to weblog entries” at the time, nor was that being gleaned from a spec that defines LINK simply as “a url that a user is expected to click on”.
ROFL!
Fantastic, Mark. Oh – and MUCH more subtle and effective than Dave Winer’s actions last weekend.
His way of proving his point was to shut down Scripting.com in an effort to “show everyone” his “point” (his words, not mine). IMHO it backfired.
Your way of proving your point is to act in accordance with Dave’s directives – eliminate the funkiness. From the chatter here it seems you proved once and for all that indeed there is a non-personal reason for formerly-known-as-Echo projects.
— DD
Mark: Not too long ago, Mr. Winer was upset by invisible ketchup smearing trunk locking dictats concerned with CSS and HTML/XHTML compliance in his weblog systems. Those ’specs’ are centralised and a standard, flogging a dead horse here.
Mr. Winer chooses to ignore these standards and progress towards them, that’s fine, his site works and we can read his commentary. Using this tenuous analogy you’re entirely justified to do the same with RSS 2.0, since Mr. Winer seems to be the person passing judgment and changing the goalposts to assert his authority — I do understand there’s a difference between CSS/XHTML and the RSS 2.0 specs, however, beneath all this it’s still one rule for Me and one rule for Them.
I will not unsubscribe, it’s not my position to chastise anything. You’ve made your point Mark, the conversation here is centered on trying to convince readers that your actions are on spec, from my POV it’s a nice satire. Still….maybe you could give us a choice ;) Mr. Winer doesn’t have to know about it, I’ll (we’ll) keep it a secret.
— Gummi
It would certainly be an anachronism for the RSS 0.91 Spec to mention “weblog”.
My point was the <link> was the only mechanism for an RSS 0.91 feed to point back to the “source” of an <item>. I would venture that 99% of all 0.91 feeds use <link> as a permalink, as did (does?) Dave’s own software. Dave’s RSS 2.0 Spec clearly sanctions this behaviour. In light of his oft-stated goal of backwards compatibility with 0.91, one can hardly expect otherwise.
And his Spec clearly sanctions <guid>s *not* being permalinks. Indeed, his spec states clearly that “Aggregators must view them as a string.” *Unlike* <link>, which is supposed to be a URL. According to the Spec, Aggregators should not treat <guid> as a clickable link; it’s a *string* representing a globally-unique identifier for the item.
Dave is free to change his mind. He can put out a revised Spec which mandates different behaviour. But you can’t tell me that using <link> is incorrect behaviour in RSS 2.0.
Absolutely hilarious!
Thanks Mark.
This is brilliant. It’s unthinkable for a discussion on RSS to inspire so much thought on social manipulation.
— sleeper
“and I’m now turning my attention to other matters.”
Could’ve fooled me.
Mark,
It’s too bad this campaign is about taking a*nother* shot at Dave instead of adhering to the spec, as you say.
Also too bad that the result is you’re less accessible to your readers.
Oh well.
— Disappointed, again.
Is this the same Mark who wrote the “ultra-liberal RSS parser”?
Even if it is, remember, the one correct true philosophy of protocol implementors is to parse as liberally as possible, but send as conservatively as possible. By abiding by the spec correctly, Mark is making it easier for even broken aggregators like Syndirella to properly cope with RSS. Applause all around.
If it makes you anxious and want to change Mark’s behavior, consider: why?
— Felix
Humor can be hard to communicate online sometimes.
A word of caution to those of you who think this is funny. As programmers we delight in things that are clever. But most of us are disinclined to use that cleverness in hurtful ways.
You may think that there’s plenty of hurtfulness to go around, and you may be right. But consider this. Suppose we posit that all good leaders are bound to offend somebody. How would you rather take it: out in the open with a little name-calling, or craftily and meanly?
Observe carefully what is happening here. This is your future.
Mark, are you familiar with the book “The Good Soldier Svejk” by Jaroslav Hasek? Svejk was a soldier in the Austrian Army during World War I who followed his orders absolutely to the letter, and the book is about the hilarity that ensues. You should check it out; I believe you’d find Svejk a kindred spirit.
— ralph
I give up, Rogers. Last fall I took Dave at his word when he said “let a thousand flowers bloom”, and I went crazy adding namespaced elements to RSS 2.0. In the past 2 weeks, all of this work has been destroyed, and I’ve been marked as the source of all the world’s funkiness and publicly chastised by people I admire.
http://wmf.editthispage.com/discuss/msgReader$8689
Today’s post is a 180-degrees turn for me. I am publicly repudiating all my prior work on attempting to replace core RSS elements with namespaced equivalents. I thought it was a good idea to “leverage” prior art like Dublin Core, and it is a good idea in some cases, but I see now that RSS is not the place for that kind of thing.
Therefore I have reverted to a completely non-funky RSS feed. This is not a stunt, and it’s not a satire, and you’re not going to wake up tomorrow and visit diveintomark.org and see a post that says “ha ha, just kidding”. This is an honest attempt to “do RSS right”, according to the spec and the intention of the spec author, so that I can stop fighting about RSS and get some real work done on other matters.
I’m done with RSS. I have better things to do than sit around, day in and day out, and argue about it. If you don’t like my RSS feed, feel free to unsubscribe. Maybe someday in the future there will be other feeds, in other formats. Or maybe not. Either way, I have better things to do.
— Mark
I take back my earlier opposition to bowdlerized comment feeds, Mark. That redlining rocks.
Mark, you should take out the bit where “Dave agrees.” I took you at face value this morning. My mistake.
Dave, if your opinion has changed since your comment that I linked to, post your opinion publicly and I’ll link to it.
I can’t imagine why you would change your opinion, though. I’m doing RSS exactly the way you want it done (and backing up every bit of that statement with links to your own thoughts on individual issues). Is there something else I should be doing? Damn, I thought I finally had this right.
— Mark
Update (I hadn’t seen Mark’s #78 comment when I posted the above comment.):
Mark, If you’re truly serious about this last “180-degrees turn” and if you truly wish to “leave RSS alone” and stop the FUD-slinging, then you should consider a little more balanced approach in your RSS publishing.
At least put the <link> tag back in there, because – as several people have pointed out – linking to your original content is a perfectly valid use of the <link> tag and respects the common usage of that tag.
Furthermore, you should feel comfortable about dropping some of the namespaced elements back into your RSS to *supplement* the core tags – not to replace them. Everyone aggrees that using namespace tags to supplement the core is not funky at all.
If you don’t, then I stand by every word of my critique above.
Oh, and I gather that he doesn’t like my orange buttons either. That’s just too bad.
Personally, I’d rather be insulted directly than recognize, long after the fact, that someone’s been taking shots and I’m too dense to notice.
Here’s a “clever, clever boy” to you anyway, Mark, and to all the uncertainty you’ve managed to spread today about RSS 2.0 by bastardizing your feed and treating everything that Dave Winer has ever said about RSS as if it were part of the specification — even comments that Dave has labeled as his own opinion.
You must have gotten quite a chuckle when Dave thought you were on the level with this post and said on Scripting News, “Mark Pilgrim is making total sense. If he does his work openly we’ll all learn a lot because Mark is a great teacher.” I see he’s taken that down.
May your own “well-documented, well-maintained, well-organized, and (I hope, someday) well-supported” format one day attract someone half as clever.
Hmmm.. Mark, last time I checked It was considered bad “blog manners” to edit an article/entry after the fact to drastically alter its meaning like you’ve done with this post.
Amazing how you manage to turn a surprisingly reasonable post into Yet-Another-Pissing-Contest with Dave. Yet another powerful FUD strike on RSS from you.
Subtle, clever (I’ll grant you that) and spiteful.
In comment #4 above, I commended you for what I thought was a great post at the time. Now, after your last “update”, my words stand as if I was endorsing your pissing-contest. Sorry, but I do take offence. Futhermore, it was in very poor taste to wait for Dave Winer to praise you and then do the pissing-contest thing on him right afterwards. Shame on you Mark!
IMO you’re acting childishly. I hope that you’ll grow out of it some day.
[Feel free to delete this comment if my critique makes you feel uncomfortable.]
Mark, you can point to this post for an explanation of why I withdrew my endorsement of this project.
Mark apparently thought I was telling him to “break your users” when I was really saying “in my humble opinion.”
He’s wrong about the RSS 2.0 spec changing, it hasn’t changed. Not one word. Not one piece of punctuation. Nothing about it has changed.
“linking to your original content is a perfectly valid use of the <link> tag and respects the common usage of that tag”
Except that Dave has publically deprecated the usage of <link> as a permalink in favour of <guid>.
“Everyone aggrees that using namespace tags to supplement the core is not funky at all.”
As I read Dave’s recent pronouncements, he is deprecating *all* uses of namespaces in RSS 2.0, not just the use of tags like <dc:date> which have cognates in the Spec.
There are two issues which this raises.
1) If RSS 2.0 is “frozen”, you can’t go about *changing* it. You can propose a new Spec (RSS 2.1 or DSS 1.0 or whatever), but you can’t wake up one morning and decide that what was previously perfectly legal and within Spec is now “Funky” and out of Spec.
2) While he professes not to “own RSS 2.0″, in making these pronouncements, Dave is certainly *acting* as if he owns the Spec, and can change it at his whim. (Nobody else can change it, ‘cuz it’s “frozen”.)
Now, I like a good pissing match as much as the next dog, but my attitude has been to tune Dave out. When I see a Specification (as opposed to a blog post on scriptingnews.userland.com) I’ll consider changing my feeds to adhere to the new Spec.
Until then, my feeds are valid RSS 2.0 (as per the Spec) and are not going to change just because Dave says they’re “funky”.
Shooting at a moving target is difficult.
It is even more difficult if, when you get it, someone arrives to tell you it was the wrong target, and you have to start all over again.
This is, I think, the point Mark tries to show us. What makes Mark’s feed (now) different from, say, BBC or Slashdot uses of RSS?
While, in this whole discussion, I’ve tried hard to avoid taking a clear position, as I always prefer integration, it looks more and more impossible to sustain such a goal, at least during the process. Maybe after the non-Echo initiative settles it will suddenly become possible and desirable again.
I think this is also the approach Sam Ruby is taking. Sam will go to incredible work to keep discussion on technical grounds and clear politics off it, and express rationale of decisions. Mark, on the other hand, will go to incredible work to show (his perceived) inconsistencies. ;-)
RSS is easy and it works well for what it does. It’s easy-ness is why it is so polular. It’s got that “I can learn it by doing view source” kinda mentality that rocked HTML into the limelight. Keep it.
— Robert S
Robert S: Amen, right on and thank you.
It was no accident that RSS is so simple.
Mark P, who seems to read everything I write, may have missed this one.
http://davenet.userland.com/2000/09/02/whatToDoAboutRss#rssIsAboutSimplicity
“RSS, in its simplicity, is a breath of fresh air. You can understand it fully in a few minutes. You can quickly deploy an application with just a basic understanding of HTML and a bit of experience in a scripting language like Perl, AppleScript or Python. That is the reason it gained traction, while most other XML formats are still in the working groups or waiting for deployment. In the overworked world of Web development, there’s no time to study, there’s only time to do.”
James Robertson wrote: “So if your goal was to be read less, you have succeeded.”
I disagree. Mark, you have succeeded in making it *more* likely for your blog posts to be read since I tend to remove bloated RSS feeds (those that contain a load of content instead of concise summaries) from my subscriptions. A good summary will let readers decide whether they want to read a post (in a browser, not an RSS reader!) at all.
A feed with content is just a waste of bandwidth as far as I’m concerned since a) when I do want to read it I’ll load it in a browser (providing me with all the tools a browser does but an RSS reader does not and should not) – thus forcing me to download that content twice, and b) if I don’t want to read it I’ve downloaded what I don’t want.
See also my comment on http://www.sauria.com/blog/computers/internet/weblogs/305
Thank you for your new feed format!
— Anonymous
Jacques, both of your objections are based on what Dave Winer thinks or feels, but I don’t think that is a valid objection, especially coming from your or Mark. Coming from you guys, it just sounds like irony.
Sorry, but I don’t buy this whole Dave-is-God-and-if-he-says-he-likes-jumping-we-must-all-say-how-high argument – with or without the irony bit.
I’m just neutral bystander who has tremendous respect for people on both sides of the argument, and I like what RSS is doing and has done in the personal/amateur publishing world, and I don’t like it when I think people I usually respect are repeatedly slinging tons of FUD on everything RSS stands for – seemingly just to get back at Dave for something or another.
I like the fact that I can publish my own RSS feed and it brings a bunch of readers to my site every day, and I like to use RSS feeds and a dead-simple web-based RSS aggregator to follow what’s going on on most of the websites/weblogs I like to read.
When a clever and popular person like Mark does something stupid, loads of people emulate that stupidity. So when Mark decides to go all ironic and “Dave-is-God-so-I’m-dropping-the-link-tag-from-my-RSS-feed” on us, then two things happen:
a) Mark’s RSS feed stops working in my Aggregator
b) The RSS feeds of several other people are likely to stop working soon after.
Both of these things make me sad.
Sorry, but my bullshit-sensor is maxing out on this whole affair.
Let’s cut the f… irony and get back to a) *peacefully* trying to improve interoperability in RSS land and b) create some true non-zerosum forward motion in (not-)Echo land.
Sorry my previous comment post (#95) turned out anonymous – that was not the intenton. Somehow, trying to preview-and-edit I lost the content of the “name” and “home page” links.
Currently this discussion has roughly as many comments appended as the previous five combined; this is being read less?
Mark, would you please consider reporting your traffic before and after the change, once enough time has passed to establish the new trend?
— Danil
Mark, are you updating your example templates to reflect your new interpretation of RSS 2.0 (and if so, would you keep the funky templates available for those not yet ready for a vow of chastity)?
— xian
xian: thanks for the reminder.
http://diveintomark.org/about/templates/
now links to the new-and-improved templates for my main RSS feed, comments feed, “nothing personal” feed, and category feeds. Anyone who wishes to produce RSS like this is free to use these templates.
— Mark
Mark,
It’s pretty obvious to me (reading the same stuff by Dave that you’ve pointed to) that when an RSS feed does *not* contain the full content, then [link] should absolutely still be used to point to the full version of what is being described by the post in [description].
This does not negate the fact that full content feeds that lack [link] are likely to still be semi-broken in many aggregators, but recipients of full-content feeds are less likely to need to click the link anyway.
I think that Mark’s point is spot on. Sure, it may be common practice to use <link> in parallel with <guid> but if you followed the spec, you would more likely arrive at what Mark has written than Radio’s empty link behaviour.
I can understand why Dave is peeved, but ultimately why Mark did it doesn’t change the nature of his RSS. If it was good earlier when Dave thought Mark was agreeing with him, what is different now? The aggregators would still have broken. Mark’s intent is really beside the point.
The aggregators need to be fixed. RSS doesn’t need to be fixed. (not-)Echo needs to continue its forward motion.
— huxley
I was congratulating myself on not getting sucked into ‘Big Brother’ — the reality television show — when I realised that I was following it right here on the web… : )
— nardo
Thanks for the laughs, Mark. You put on a darn good show. I think it might be more fun if you started basing everything solely on Dave Winer heresy, though, instead of taking it directly from his sites. I mean, it’s not like it makes sense now, so why not? Try this google query for ideas:
“dave winer said|says” -site:scripting.com -site:userland.com
— phyx
When you have to choose between basing your (site|feed|life) on Dave Winer hearsay and Dave Winer heresy, it’s time to rethink things.
Wow, if only the word ‘heretical’ had been used rather than ‘funky.’
— jacob
Mark, the archived posts where you refer to your “funky” RSS 2.0 now refer (I checked yesterday) to the new non-funky 2.0 feeds, making tracking of the issue very confusing.
You should change the URIs of those posts to point to some older (static?) funky feeds, or people arriving late will get crazy trying to understand.
Or, at least, update those post pointing to the future, for the benefit of people trying to get the whole picture.
Nice stunt, Mark. Almost as good as the Platypi. Now can you please go back to LEAVING RSS ALONE! and use the core of RSS (title, link, description) rather than taking advantage of link being optional and using the later addition of guid instead. Then I can feel comfortable about reading your RSS in my RSS reader.
Regardless of the ambiguity of various comments and the comment on link in the 0.92 spec, I’m a firm believer that link should be the permalink of the story encoded by item. I think that the 0.91, 2.0, 1.0 specs, the example 0.91, 2.0 and 1.0 files and the RSS marketplace all agree with me. See http://www.voidstar.com/node.php?id=1421 for a more complete reasoning.
Re: “Wow, if only the word ‘heretical’ had been used rather than ‘funky.’” – Jacob
No one expects the Spanish Inquisition.
— Anonymous
Julian: but this is the way Frontier does it, and it’s clearly in line with Dave’s clarification on June 25th.
I could, of course, revert to a previous version, like RSS 0.91. (But which RSS 0.91? There are 2.) But all previous versions have been deprecated by RSS 2.0, which adds important new features like [guid]. If I want to do RSS exactly as UserLand does (and I do, I do), it’s RSS 2.0 or the highway.
— Mark
So, do it like Radio does it, not like Frontier. Since your site is, in fact, a weblog.
Frontier runs weblogs.
http://thebase.weblogger.com/xml/rss.xml
— Mark
Imagine this conversation, and Dave Winers part in it, and all the others who have joined in, from the perspective of a total RSS newbie/outsider.
Lets use me. I’ve used RSS as a user for eons; and consumed other people’s RSS as a developer in a lightweight manner for a few applications.
I’m in the process of building a multi-lingual CMS (which can also drive a blog) and have rather purposely left any consideration to RSS (or similar format) until the end — but not just because of the on-going controversy — partly for the confusion that exists.
Given that the blogoscenti are arguing whether a new format its need, but also about how implementation details of existing specs, some in broad use for years, are not clearly agreed upon by all — what’s a “new” developer to this scene to do?
I can tell you what I’d like – a clear, concise, universally agreeable format where everyeone agrees on what each elements purpose is, on what data each can contain, encoding, etc.
Its painful trying to sort out what is right vs wrong in the current state of things. Hopefully n-echo’s goal is to solve this otherwise I don’t see much future for it.
I’m attempting to stay away from all of this until the dust settles but once in a while a post catches my eye that seems to illustrate “aha, there is confusion in the current state of RSS affairs”. Whether that its true or not, doesn’t matter. The fact that its so easy for a newcomer to writing RSS generators and consumers to be sidelined by apparent inconsistencies should be an indication that something is wrong.
What’s a poor newbie to do? Hopefully all this angst, good discussion, testosterone and fun will result in some picture that looks good to all.
— Mike
Mike: one of (not-)Echo’s 4 primary goals is “a new weblog format that is cleanly and thoroughly specified”.
http://www.intertwingly.net/wiki/pie/RoadMap
— Mark
Mark – I know, and that’s one reason why suffering through the angst is worthwhile.
When I first started to look at what my RSS implementation might look like, I did what every web developer does at some point – “view source” for dozens of feeds. You already know what I saw – many different interpretations of what a blog, blog post is, different uses of link and guid. Different date formats, you name it.
So I do see this n-echo effort as being very useful to get past the friendly chaos which has persisted until now, and disagree with Dave Winer that relooking at anything hands the keys to the “bigs”. A well done spec now, along with broad support by smaller co’s, popular co’s, and individuals, would seem to be the best defence against MSFT or IBM or Google taking and perverting it to their own benefit at the exclusion of others.
— Mike
Why is there no repies to posts #37 (Jim) and #102(M. Bernstein)? It seems to me that these interpretations of the “spec” are valid in regard to the use of link.
— Claude
Why is it important to produce “pure RSS” that breaks most RSS readers when we can see browser-specific code in the CSS used by this site?
— Claude
Because at this point, its still possible to influence the bulk of the RSS readers, where as its not possible to influence the bulk of browsers (IE by default).
Are you suggesting that “standards” are not worthwhile Claude?
— Anonymous
Sorry, I should say that I assume its “Because at this point…”
Don’t wan’t to put words in Mark’s mouth.
— Mike
Mark, while you can choose to interpret Dave’s statements in the way you have (deprecating [link] in favor of guid entirely), it’s also clear that the intention (for feeds that do not include their full content) is that link continue to be used to point to the article described in [description] (which, for your weblog, is actually the same as the guid/permalink of the entry).
Given that choice of interpretations, please either add [link] back, or change the feed to include the full content in [description].
Thank you.
re: Are you suggesting that “standards” are not worthwhile Claude?
Of course not. But please do not look at the source of my non-rss-tag-soup-site as a proof of my belief ;-)
Answers to these questions would help me decide if this current post is educational to me, or if it is just troll-blogging.
— Claude
Any aggregator that claims to support RSS 2.0 but does not support [guid] as a permalink is broken. Quoting from the RSS 2.0 spec:
“”"
If the guid element has an attribute named “isPermaLink” with a value of true, the reader may assume that it is a permalink to the item, that is, a url that can be opened in a Web browser, that points to the full item described by the [item] element.
… isPermaLink is optional, its default value is true.
“”"
http://backend.userland.com/rss#ltguidgtSubelementOfLtitemgt
— Mark
Mark,
True, but if you have the option of trivially accomodating those broken aggregators while still complying with the specification, why wouldn’t you?
My opinion: Trivial accomodation means the broken aggregators remain broken, thus no encouragement loop starts.
Trivial accomodation therefore creates defacto standards which aren’t “standard”.
Coming from the other side, we have Internet Explorer which doesn’t even handle fairly simple standard markup in a standards compliant way. Look what a mess creating HTML markup is, thanks to lack of specification compliant browsers.
Do Michael and James propose that go down that road? Do you really want to instill that culture into the RSS / syndication community? Do you really?
— Mike
Hell, I’d take an MD5 hash of the original content as [guid], I don’t care.
— James
Original as posted by Mark: “Any aggregator that claims to support RSS 2.0 but does not support [guid] as a permalink is broken.”
As it should read from reading the spec: “Any aggregator that claims to support RSS 2.0 but does not support [guid] as a possible permalink is broken.”
— James
re 126:
Because he’s being childish in making his point as to why we need Necho and why Dave Winer sucks.
— James
Re 128:
I use RSS 1.0 so I don’t care either way. However my secondary RSS 2.0 feed uses [guid isPermaLink="false"]POSTID@http://them.ws//guid as my [guid] element which is completely valid as to the wording of the spec.
In this particular argument these arm my feelings. I’ll offer my opinions afterwards.
However my interpretation of [link] leans towards the “if your description is a summary of your original content then using [link] as a url to your posting is valid” school of thought, while [guid], in this case, can either be a permalink or not, depends if you want it to be.
Now for a full description is where it becomes [link] points to the first URL or the “point URL” of the posting and [guid] is the permalink for your post, or not depending if you use isPermaLink=”false”.
Since Mark’s new rss feed is the former using [link] in this way is not a violation of the spec.
Here are my feelings towards what [guid] and [link] are.
And let’s remove the “first url of the entry” issue shall we in regards to [link]. In lots of cases it’ll be something like “Found at Bob’s Blog who found it at Kim’s Blog” so the [link] should be the url to Kim’s blog, not Bob’s, in the cases outlines above.
However if you ask me [guid] should be to Kim’s blog. Why? Simple. guid means globally unique identifier. Imagine how great it would be if everyone followed that and when blogging about a particular topic/meme used the [guid] to point to the “first.” That way Aggregators could use smart filterings to group posts about a specific topic together.
Further on [guid], if it is supposed to be a permalink, why even have the option of isPermaLink=”false”? Why have the content being just “a string”? None of these scream out to me [guid] must be the PermaLink for your entry.
[guid] is something that uniquely IDs your entry. If it’s all original content it’s the permalink to your URL. If it’s about another entry it’s that URL.
[link]s short description can easily be inferred to mean URL to your entry. How? Simple. look at [title]’s. “The title of the item.” There is no argument as to what [title] means. It is the title of your entry, not the title of an entry you are linking to. Now look at the wording of [link]. “The URL of the item.” Going from what we know about [title] “the item” refers to your posting, or that particular entry. So using this prior knowledge we take [link] to mean a URL pointing to the original entry.
If we went with the belief that [link] points to a url from the item every core element has a new meaning. [author], Email address of the author of the item, means auther at the end of the URL, etc. It all lies in how you define “the item.”
If you ask me these are the ambiguities and short commings in the Spec Mark is hilighting in a childish way by doing RSS “Dave’s way.” [censor reason="flame"]We are so much smarter than Dave we wont have these problems in our overly engineered spec there wont be any confusion as to what any item means or can contain. Sure it’ll be harder to produce and implement, I thought Mark was tired of waiting for tools? Or does that only apply to RDF?, but we’ll be better off with it than without it.[/censor]
— James
From the 2.0 spec. “Guid … When present, an aggregator may choose to use this string to determine if an item is new.” I always understood that this was the primary reason for having an item.guid. it makes it easier for an aggregator that is reading an RSS feed repeatedly and storing the results, to tell if this item is the same as this stored one. The use of guid to store a permalink is secondary to this.
By contrast link has been around since the beginning and the de facto standard in aggregators is to use it to provide something to click on. (How’s that for obvious!). So as a feed creator, providing a url attached to the item via link, you can be pretty sure that it’s going to get presented to the user as a clickable link. So where do you want it to go? Judging by the overwhelming majority of cases, almost all of us say “to the webpage showing my full item”.
Given all the specs, example feeds and code associated with DW, and even the most recent comments, ISTM that DW accepts that this is a perfectly valid use of link. The confusion here comes from DW’s comments that there are other valid uses of link. But even this doesn’t violate the spec. Although the lack of consistency may irritate the feed consumer a little.
Mark, you’ve been quoting the guid spec to justify leaving out link. But I don’t see anything in the spec that says that if you have a guid, you should leave out link. What I see is that both elements are optional. So you can choose to include either or both. And while Aggregators are encouraged to support all elements of the spec, they can also choose to not support elements which are optional or less widely used. While I think we should encouraging aggregator authors to support all elements, we shouldn’t be forcing too many interpretations on them. Like saying if guid exists and is a permalink, ignore link and use the guid as the clickable link presented to the user.
Perhaps what we actually need is a best practice document that recommends some approaches and deprecates others.
So I’m just going to repeat it again. Channel, Item, I.Title, I.Link, I.Description (CITLD) are GOOD ENOUGH. DON’T MESS WITH THEM. They may be optional but they are also desired so use them if you can. And then and only then work on new elements and namespaces.
Julian, if I were using RSS 0.91, I would absolutely agree with you. But the semantics of RSS 2.0 are different.
re: “But I don’t see anything in the spec that says that if you have a guid, you should leave out link.”
That’s what the subsequent clarification was about.
http://scriptingnews.userland.com/2003/06/25#theLizardBrainOfRss
Really, we’re been around and around with this. The RSS 2.0 spec introduces [guid] and clearly defines it as a way to express a permalink. The clarification of June 25th clearly deprecates [link] as a way to express a permalink, in favor of [guid].
Hopefully someday this will be rolled into the main spec so there is less confusion, but until then, you can read both for yourself and interpret them. I stand by my interpretation.
— Mark
Mike writes, “Trivial accomodation means the broken aggregators remain broken, thus no encouragement loop starts.”
I don’t think RSS 0.9x/2.0 has ever been about “encouragement loops”. The emphasis has been on backwards compatibility with existing tools and feeds.]
Also, I don’t see anything in that “lizard brain” essay to suggest it is anything more than one opinion on how to use LINK and GUID are concerned.
Mike,
I would take a hard line against trivial accomodation if it wasn’t standards compliant. That’s not the case here.
Mark,
While [guid] can (and should) be used as a permalink for the web-representation of the [item], [link] has an older role, that of pointing to the article that the [description] describes.
It seems to me that that older role is still firmly held by [link], and nothing in the clarification you pointed to makes me think that that older role of [link] has been taken over by [guid], even when isPermalink=”true”.
Since your feed has excerpts only, you still need a [link] to point to the article that the [description] describes, in this case the full version of the posting on your site.