It’s just data

There is no FAQ

Dave Winer: link should be used only to link to the article being described by the post

This type of information is most helpful.  I could imagine modifying the validator to flag items whose link tag appear to be relative to the enclosing channel's link.

Dare Obasanjo

Interesting comment by Dave. However experience has shown me that most RSS feeds that have a  element use it as a permalink. More importantly I've always considered that concept broken because it implies that a blog post must be linking to some site instead of creating original content and even more it must be linking to only one site.

This is an extremely narrow view of blogging.

Message from Dare Obasanjo at

Wouldn't that catch I thought Dave said was OK.

Posted by Aaron Swartz at

I completely agree with Dare. <link> should link to original content on your site, not to whatever that content may be talking about.

I think something like dcterms:references would be better suited for that purpose.

Posted by Luke Hutteman at

I'm a big believer in using meaningful names for things... I think the reason some people use link inappropriately today is because the name "link" is ambiguous.  Using the name relatedLink, or something more indicative of the semantics, will decrease the likelihood of this happening for the next round.

In summary, I think whatever comes out of the permaLink discussion should be separate from an optional (perhaps list of) relatedLink tags or somesuch.

Posted by Chris Wilper at

If this is the case, I'm shocked.  It's the first I've heard of it, and I wrote the f*ing validator, which is not to say that I'm god, but merely to say that I've volunteered to dive deeper into RSS arcana than almost anyone else.  And this is news to me.

Posted by Mark at

Sorry, that should have been "we wrote the f*ing validator".

Posted by Mark at

According to this new (COMPLETELY UNDOCUMENTED BEFORE TODAY) rule, UserLand's recently-announced New York Times RSS feeds use LINK incorrectly.  See, for example:

Worse, they have a GUID that claims to be a permalink (doesn't have isPermalink="false", so it defaults to true), and they also have a LINK which actually is a permalink.  The spec does not specify precedence order, but given this new rule, I'm guessing that GUID would take precedence, which is unfortunate, because the LINK is a better permalink (it includes the extra query parameters to view the article without login cookies).

Posted by Mark at

It sounds like Dave is asking that we use the link tag as it was originally used. Back in 1999, the format to me looked like it was based far too much on a newspaper model, where every post was about one thing, located somemwhere else. Most blogs back then were link-driven, so it wasn't unheard of, but I thought the single link limit was ridiculous at the time.

I brought this issue up in 1999 with someone that worked on syndication, because I thought it was a far too narrow view, sort of pulling round weblog posts into square newspaper-era holes. It felt like having the syndication format dictate how we write, and it's why I didn't even have a RSS feed for my personal site until late last year.

Posted by Matt Haughey at

I have to admit I was totally confused when I read Dave's comments on <guid> this morning.

Reading this thread I understand what he was trying to say, and now I think its just a bad idea.

There are dozens of ways you could syndicate this info if  you wanted to (dcterms:references seems like a good one) but putting it at the heart of RSS suggests that its only useful for syndicating the very early proto-blogging style of "link and blurb".  How narrow.

(There is no FAQ, like this is no cabal?  or more like there is no cat?)

Posted by kellan at

Arrgh. Not again. 99% of all the RSS out there that has a &lt;link> uses &lt;link> for the permalink of the article of which &lt;title> is the title and &lt;description> is the abstract. I've never liked the idea that link should refer to the first article pointed to in the description. I like it even less now that this approach is in the (very small) minority. This is particularly important where &lt;description> is not complete and really is an abstract. In that case when clicking on the title-link in the aggregator you get taken to the full article, not somewhere else entirely.

So I look at all the RSS generated by Radio that doesn't have a &lt;link> at all and wonder why, when every post does have a permalink.

Hmm. I seem to be repeating myself again.

Posted by Julian Bond at

Re the validator issue. Yes, a validator should check that &lt; is not relative to the channel. It should be a fully qualified URL. IMHO.

Posted by Julian Bond at

What Dave said is somewhat confusing. Perhaps it should be, "link is a link to an external representation of the thing described by, or in, this thing"?

In either the case where the format is a means of syndicating (read: distributing) content, or in the case where it is an excerpt of that content, the use has not been merely to comment on something external to oneself &mdash; which is how Dave's statement reads.

Posted by at

Mark, there's absolutely nothing wrong with the link and guid in the feed you pointed to.

Matt, I totally agree that that model for publishing comes from professional news organizations, but a lot of them use RSS to publish their news. As I said in today's writeup, the BBC released 68 new feeds yesterday that use exactly the model I describe. The Times uses that model, as does Christian Science Monitor and ComputerWorld. All of them are very important (imho) users of RSS.

Posted by Dave Winer at

The way UserLand's manila, and later Radio, use the link is to let the authors type a link related to the title's subject.

Without an author-provided link, manila and Radio insert the post's permalink.

I've been writing this way for years. It's Google and trackback friendly. It's convenient for quick posts. It provokes self-editing, at least picking the post's most important source or citation. And did I mention it's Google friendly?

What you're suggesting is equivalent to replacing the url you use with this post (the one surrounding your name) with a permalink. This is less user content, not more.

If you want a permalink element, please add one and leave the link element to its dual use.

Posted by Phil Wolff at

One other clarification. The link element url is by no means the first url linked to in the description element. It is often unique and may be the only external link associated with that post.

Posted by Phil Wolff at

If "link" means associated link, then a well-formed weblog post should be able to have zero or more links.

Posts often refer to multiple external reference (depending on the style of the blogger)

Posted by Adina Levin at

I totally agree that that model for publishing comes from professional news organizations, but a lot of them use RSS to publish their news

My point is that what works for professional news organizations doesn't work for my personal blog which may have anywhere from one link to ten links, or most often, none at all. I agree that the single outbound related link in RSS is perfect for the BBC's stories, but a single outside related link for each entry isn't a useful format for the majority of weblogs being published today.

Posted by Matt Haughey at

Dave's point about commercial publishing users of RSS is valid.

If we're talking about a new or updated syndication format, commercial publishers have a valid set of use cases that should be represented here.

The interested parties aren't just pro publishers. End users use aggregators to read weblog content, community blog content (slashdot), and pro news (nytimes).

Is there a reasonable implementation space that has weblogs only in mind?

Is this a viable decision, given overlap between amateur, semipro, and professional publishing?

If so how would a new standard interact applications that have those pro publishing use cases?

If not, should the conversation invite other use cases from professional publishing?

Posted by Adina Levin at

Adina: inviting the 'pros' would be a most excellent idea, IMHO.  Suggestions?

Posted by Sam Ruby at

Dave: you're right, I'm wrong, UserLand's NYT feeds use [link] the way you said this morning that everyone should use [link].  My apologies on creating even more confusion today.

Posted by Mark at

Does Tim Bray still have contacts in the space?

Also, I can ping the Seybold people and ask them to refer folks to this discussion.


Posted by Adina Levin at

Now then, I've done some digging, and this problem of "what should [link] point to" is not new.  Apparently RSS 0.90 (released by Netscape in March 1999) was designed exclusively for pointing to external content.  At the time, Dave complained about this, and saw it as a primary reason why his competing [scriptingNews] format was better.  (Briefly, it had multiple links per post.)

When it became clear that Netscape was not going to work with UserLand (or anyone else) on RSS 0.91, Dave revved his competing [scriptingNews] format (to add some features of RSS), and continued to lambast RSS for not supporting multiple links per post:

RSS is woefully inadequate. It's missing the key thing web writers and readers need. A channel is not a series of links pointing to articles, it's a set of paragraphs that point to one or more articles per paragraph. We told Netscape this, and they said they would work with us on the next rev of the spec.

Now, being an experienced commercial developer for twenty years, I know that such promises mean almost nothing. And with all the departures at Netscape, it's not surprising that they went forward with the next rev without our help. When I became aware of this, we immediately tooled up a new version of our format, and addressed the issues needed to bring it to parity with RSS.


Writing happens in paragraphs. Web writing allows links to be anywhere. To limit channels to one link per paragraph is not good! Technology serves writers and readers, they shouldn't be limited by technology.

Not sure where that leaves us, just wanted to note that it's an old battle.  I think Dave is secretly trying to get us all to convert to [scriptingNews] format. ;-)

Posted by Mark at

This is is what RSS 2.0 spec says about an item's [link]:

An item may represent a "story" -- much like a story in a newspaper or magazine; if so its description is a synopsis of the story, and the link points to the full story.

This is how I use [link] in my RSS feed: [description] is a plain-text, hand-written (not auto-generated) synopsis of the post, and [link] is a permalink to the actual post.  This is how most weblogging systems use it (although most auto-generate the [description] synopsis).  Is Dave saying this is wrong?  If so, why?

Posted by Mark at

Matt, and now you are in a position to explain to Julian why some RSS sources only have descriptions and no links or titles.

And Mark, that was the compromise. Look at the quote everyone is attributing to me about compromise and great things happening. 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. It was the same reasoning that led me to support the Blogger API in favor of ManilaRPC.

Posted by Dave Winer at

Do I have this right?

1) In the most traditional use of RSS, a news site syndicating headlines, the description should be a short summary of the original article, and the link should be the URL for the article itself.

2) In the classic style of weblog, a series of short posts describing things elsewhere on the web, the description should be the full text of the weblog post, the link should be the URL that the post talks about, and the guid should be a permalink to the post itself.

3) (This is the part I'm least sure of.) A weblog like Mark's, which is mostly a place to post longer linkless articles, is more like a news site than a Title-Link-Description-style weblog, so the same rules apply as in case 1: description should be a summary, link should be the URL to the full article.

A good rule of thumb would be: the link should always point to something with more content than is found in the description alone. (And, in weblogs, the guid should always be a permalink.)

Posted by Moss Collum at

Moss, that's a great synopsis, but I'd add that very few people follow the second case listed. Ideally, a new format should support any number of links, both inbound and outbound. I think everyone was kind of surprised at what Dave wrote today because few people do that second use anymore and most weblog software ships with the third case in mind, out of the box.

Posted by Matt Haughey at

Speaking as an outsider to the RSS wars, I have to say that this sort of ambiguity is a nightmare for RSS consumers.  One element should contain the permalink for the entry.  Another element can contain the links referenced by the entry.  One element should contain a description/excerpt/synopsis.  Another element can contain the full text of the entry.  This just strikes me as sane.  Needless ambiguity in something  as seemingly simple as RSS strikes me as irrational.

Posted by jacob at

Moss, I think you got it right. And I still don't like 2) or see the need for it. I'd prefer firstly that links in the article text are embedded as encoded html in description and secondly that there was a formal xml extension to attach a list of those links to the item.

Dave, I can understand why there might be no title. I find it harder to understand why there should be no link where the article does have a permalink.

And I'm further confused by the description of news organizations such as the BBC. I look at BBC feeds and the items and the link element in those items points to the permanent location of the BBC article via a redirection so they can gather stats. So effectively the link is the permalink. Which is Moss' version 1).

I think at least some of the confusion here comes from some ambiguity in the wording in Dave's original statement at the top of this page (and in the 0.9x specs). Where is the "article" and "post"? It's not always clear to me what either Dave or commentators mean by these. Sometimes it seems to be the paragraph or article being encoded in the item. Sometimes it seems to be some external web page that is being commented on in the article encoded in the item.

So my vote is for
- Moss' type 1) to be a recommended approach
- All other approaches to be deprecated
- Work be done on a way of encoding multiple external links per item.

Posted by Julian Bond at

I thought everybody agreed with Tim Bray, that syntax was enough? As long as everyone uses 'link' it doesn't matter what it means...

Posted by Danny at

Danny, I realize that you are trying to make a point, but please try to find a less personal and more constructive way in which to do it.

I note in your RSS 1.0 feed you make use of dc:date.  Is this the date the item was created, issued, or modified?  Or is it something else?

At the present time, even if a feed is valid, about all you can assume is that a link is a url and that a dc:date is timestamp.

If we do a fresh start, lets see if we can agree to use more precise terms?

Posted by Sam Ruby at

Sam, apologies if it came across as personal, but Tim has asserted this point forcefully on the Wiki and elsewhere, e.g.

"If we agree on a syntax, with a formal decision procedure (aka validator), then we have a crystal-clear basis for interoperation."*

According to the 'consensus' everybody agrees with him. 

Apply this argument to the case of 'link' - the syntax is agreed, there is a validator, therefore it's crystal clear. Yet even this late in the game someone can turn around and effectively say it's been used wrong all along. Had this been specified more formally on a semantic level, this misunderstanding could have been avoided.

re. my dc:date - you're absolutely right, it's lousy. I'm having a site clear up next month, fixing the feed's high on my list.


Posted by Danny at

Danny, There does appear to be much consensus in that thread.  But first, let it be noted that the ambiguity of the meaning of the link tag and the interoperability problems that creates is a perfect counter-example to the narrow excerpt that you have quoted above.

There does appear to be consensus that definition of interop should be based on the bits that go across the wire.  This statement certainly resonates with me as I have spoken on the subject many times.

Furthermore, the consensus seems to be forming on the first statement quoted below.  And I see no one objecting to the second statement, which I interpret as a commendable and welcome offer to help.

I certainly agree that the primary syntax should be simple, vanilla XML. I also think that whatever happens it will be essential for Semantic Web compatibility to also provide a standard RDF/OWL mapping (to the RDF model, not RDF/XML).

Posted by Sam Ruby at

Adina, Re: pro, semi-pro, amateur

I have heard negative comments about Linux being amateurish as late as 2002 in Spain's IT circles. Now they won't acknowledge having said it, of course.

I think weblogs are already becoming a very important source of information and analysis. In other words, I think Dave Winer will win this bet, and not just because of what Tim Bray says  and Joe Gregorio refutes.

This does not mean that "pro" publishers (meaning traditional news sources) cannot have a say in a syndication/publishing/CMS_transfer ;-) standard, They must. It just means that they are no longer the only (or leading, I think) players.

Posted by Santiago Gala at

Hmm. This link thingy baffles me. Not because of the point Dave makes - actually I am using the link element in exactly that way from the first day I blog :-), but because I think it might be something to do from where people come to blogging.

My first contact was with Radio and - so I think I picked up that style rather instinctively and blogged for the first weeks without title and link, putting all links into the post content itself.

Later I implementend my own blogging tool and implemented it TLD right from the start. But I still used it in a "radio" way - reading my aggregator and blogging away. So the LINK element points usually to the prime source I am commenting. One source, one comment. Additional links go into the description element, as they are only related, not primarily links.

Maybe this could be made more clear in the EchoSpec, so that you have the primary link and related links?

Leaving the permalink in your linke element makes  no sense if you already have a permalink element that requires it's content to be a link to your post. This would just double content for no real benefit.

Posted by Georg Bauer at

re: "Yet even this late in the game someone can turn around and effectively say it's been used wrong all along. Had this been specified more formally on a semantic level, this misunderstanding could have been avoided."

I disagree completely.  "Formally specifying semantics" is a red herring, a pipe dream.  There is always the chance for ambiguity when it hits human ears.  Furthermore, even if it were possible, it would be so outrageously complicated that it simply wouldn't be worth the effort.

Formally specifying syntax + a few examples is a "good enough" solution that strikes the right balance between [chance of important ambiguity] and [barrier to entry of implementation].

Posted by Mark at

Some words are being used in both abstract and concrete cases. This confuses the thinking about those things, because one may use the word in the abstract sense, while another may read the word in the concrete sense. That's English for you.

Perhaps it would be easier, at least for us liberal arts types, to use generic terms, such as this, that, and the other, supplementing this with cases where this explains that.

So, in the case of the thing, permalink, and the thing, postid, the former is where a thing is, while the latter is what a thing is.

In the case of the thing, link, and the thing, guid, the former is, well, where a thing is, while the latter is what a thing is.

In the case of the thing, URL, and the thing, URN, the former is where a thing is, and the latter is what a thing is.

Thing One and Thing Two may be the same Thing.

Now, in the case of the thing, link, and the thing, description, the latter thing describes the former thing.

The description of the thing may be thing itself.

Posted by Will Cox at

Hang on Sam, I'm confused. First you say that "...the ambiguity of the meaning of the link tag  is a perfect counter-example...", then go on to say that the interop should be based on the bits that go over the wire. The bits that form 'link' are exactly the same whether or not the interpretation at each end is the same. If the interpretation differs, as in the case of 'link', then interop starts to fail. So there is directly relevant evidence of how this principle can lead to interop problems, yet you still think it a sound basis?

I looked through the slides btw - good show! I was a little disappointed to see the Metacrap piece rear its head again, but as I still haven't finished my counter-arguments I guess I shouldn't complain.

I'll certainly help with putting together an OWL/RDF mapping for Echo.

Mark, I agree there is always a chance of ambiguity when it reaches human ears, which is all the more reason to get the machine to do more of the work. It needn't be over-complicated. In this case of 'link' for instance, a warning-style check could be done to see if it points to a local domain/path or not. Yes, it is a form of validation, but based on machine-comprehendible semantics above and beyond those that specify the syntax. One string comparison which exposes the semantics of local/remote built into http. The red herring here is the balance you describe : [chance of important ambiguity] and [barrier to entry of implementation]. Being precise about the semantics at the start makes implementation easier as you don't need the continual cycle of (mostly human) checking. The only implementations that are harder are those that are wrong.

Posted by Danny at

Danny: if the "semantics" are "formally specified" (I put those in quotes because the entire idea is a pipe dream) in OWL/RDF, then you have effectively raised the barrier to entry for new people to come and implement the format to exclude people who do not understand OWL and do not have access to the required tools to understand OWL for them.

Posted by Mark at

ECHO Update: Link vs. GUID

I am not going to pretend I understand everything that is being said in the ECHO discussions like about guid...... [more]

Trackback from


I agree that the semantics can and should be defined in the normative, on the wire specification.

I don't see how having normative semantic definitions benefit by being separate from a normative syntax.

Semantic interoperability appears to me to be just as easy by having the semantics clearly layed out in an on-the-wire specification as if they were separate.

The XML InfoSet is not good because it is the semantic model of XML, but because the semantic model of XML got lost in "what's left of SGML" syntax of XML.

Posted by Ken MacLeod at

Danny - I will never be able to fully understand what you - or anyone else, for that matter - thinks.  All I will ever have any hope of interacting with is what you DO, and in this case, more precisely, say.

As far as what you are doing and saying - you say the primary syntax will be simple, vanilla XML.  That is something I can endorse.

You say you will help produce a canonical mapping to OWL.  That is something I very much appreciate.  Please don't let anybody stop you.  It sounds like something I would endorse and move to include as a part of whatever standard results from this effort.

In return, look at what I am saying and doing.  I am trying to argue for the proper use of more precise terms.  I think we both agree on this path too.

I see a lot of common ground here.

Posted by Sam Ruby at

Mark, your statements simply are not true.

It isn't a pipe dream because people are already using this stuff for practical purposes.

I'm guessing your 'barrier' point is based on the assumption that RDF/XML syntax would be used. This needn't be the case, the kind of syntax we're seeing in the Echo examples would be perfectly suitable, as long as there weren't any major ambiguities.
The semantics could be specified using OWL without any need for implementors to understand anything of the internals of OWL, in the same way that people don't need to be XML Schema experts to produce markup that validates. It would exclude no-one. The same kind of verbal description and a handful of examples can be used to help people create data that is valid against an XML Schema can be used to help them create data that is valid against an ontology.

Posted by Danny at

(got a little out of seq there)
I won't labour the point any longer, I just think some parts of the picture are being rushed past in the hurry to produce the "application/xml" or whatever. Groundwise, I'm pretty sure there's more of it common than not ;-)

Posted by Danny at

Phil wrote "Without an author-provided link, manila and Radio insert the post's permalink."

Just for the record, the Radio running on my Mac does not do this. It leaves the "link" field blank if I don't specify one.

Posted by xian at

xian - while the link field is blank on your screen, what appears to go into your feed is the permalink... unless you specify otherwise.

At least, that's the way Radio on Windows used to work, and judging by your rss feed, the way Radio on Mac continues to work today.

Posted by Sam Ruby at

Danny, I may have missed this if you said it in a different way before my post, do you agree that semantics can be defined alongside the syntax in the normative, on the wire spec?

I ask that because I see a pattern forming in the wiki with regards to Dublin Core that would seem to be similar to what you describe.

The intent appears to be to create an on-the-wire spec that satisfies an audience of both users and language lawyers.  By being as simple, direct, and concrete as possible defining core elements (hopefully some standard derivatives, like DC does) and how to make extensions.  In a manner that presents itself more like the RSS 2.0 spec than the more formal RSS 1.0 spec.

Within the body of the spec and examples, the part end users read, very little reference will be made outside of the spec itself (not a lot of "IS A" or modeling talk).  In the normative appendices that define the schemas and such is where I would expect to see relation made to Dublin Core or other standards.  That would be where the information I think you are suggesting would go.

So I believe the argument is not that the relations can't or shouldn't be made, but how best to present them.

Posted by Ken MacLeod at

Ken - it's my bad. I've just been looking around Wiki again, and you're quite right - there are a lot semantics around, it's just that a lot of them are syntax-centric, and I guess I was getting hung up on the lack of a separate model (the easier way of doing it, IMHO). But you're right, as long as they're there somewhere, the presentation (and the OWL rules) can be worked out later. I really will keep my mouth shut for a bit now ;-)

Posted by Danny at

Ah, thanks, Sam. I guess I was just noticing that when I enter a link, Radio makes the entry title link to that referrent. When I leave it blank, the entry title isn't "hot." But that's not the feed. That's the weblog home page and archive pages.

Posted by xian at

Is it just me, or is the whole idea of having to solve this issue with an FAQ absurd?

This is the kind of thing that should be in the specification.  If the specification is ambiguous or misleading, fix that.  That way the Q won't be so FA.

Posted by Jim at

Link v Guid

Quote from Dave Anyway, I'm explaining all this background for a purpose, to say that, imho, link should be used only to link to the article being described by the post, it should only be used in the TLD context. Sorry Dave, but the RSS 2.0 spec...

Excerpt from iBLOGthere4iM at

It is clearer to me now that Really Simple Syndication isn't the right way to do Rich Site Summary, or vice versa.

<p>Two different concerns are up against each other, and they shouldn't be blended, though they would ideally be complimentary:... [more]

Trackback from the iCite net development blog at

RSS Metadata and RSS Content - I say BOTH!

RSS = Readily Significant Schizophrenia. After reading Sam Ruby's post called There is no FAQ, about what the RSS link element was/is for, and subsequent comments, it is clearer to me now that Really Simple Syndication isn't the right way to do Rich...

Excerpt from Marc's Voice at

Its All Makes Sense Now

After reading this thread discussing Dave's "clarificaton" of the <link> element, I think I finally figured out why RSS .........

Excerpt from LaughingMeme at

PS. I just discovered (through the Pie Wiki!) that the dc:date in my feed isn't so bad after all :

[[ (from the DC spec) "Typically, Date will be associated with the creation or availability of the resource." As the only required element, that would be the meaning people would expect, in the absence of any other more specialized dates. ]]

Posted by Danny at

From Craig Cline at Seybold:

"Idealliance is doing a number of sessions on this topic at SSF03.  Contact
Marion Elledge. for details."

I'll forward Marion a link to the wiki.

- Adina

Posted by Adina Levin at

Leave RSS alone

We've all been guilty of trying to remake RSS in our own image.... [more]

Trackback from dive into mark


Ah Yes ... The First Casualty of Echo Has Arrived and it is Anyone Who Uses an Aggregator and Reads Mark (or uses Feedster)

Ah Yes ... The First Casualty of Echo Has Arrived and it is Anyone Who Uses an Aggregator and Reads Mark (or uses Feedster) Well, well, well.  This really blows.  I just caught this over on Dive into Mark:  Update 2: I have removed...

Excerpt from The FuzzyBlog! at

Ah Yes ... The First Casualty of Echo Has Arrived and it is Anyone Who Uses an Aggregator and Reads Mark (or uses Feedster)

Ah Yes ... The First Casualty of Echo Has Arrived and it is Anyone Who Uses an Aggregator and Reads Mark (or uses Feedster) Well, well, well.  This really blows.  I just caught this over on Dive into Mark:  Update 2: I have removed...

Excerpt from The FuzzyStuff: aaBlog_ScottOnBlogging at

Ah Yes ... The First Casualty of Echo Has Arrived and it is Anyone Who Uses an Aggregator and Reads Mark (or uses Feedster)

Ah Yes ... The First Casualty of Echo Has Arrived and it is Anyone Who Uses an Aggregator and Reads Mark (or uses Feedster) Well, well, well.  This really blows.  I just caught this over on Dive into Mark:  Update 2: I have removed...

Excerpt from The FuzzyStuff: aaBlog_ScottsRants at

Mark Pilgrim Castrates his RSS Feeds -- Film at Eleven

Mark Pilgrim: Update 2: I have removed the namespaced elements from all of my RSS feeds. Since there is no way in RSS 2.0 (as-is) to specify both the excerpt and the full text of a post, the feeds now only contain excerpts. Also, I switched from...

Excerpt from Matt Croydon::postneo at

No namespaces

Following in the footsteps of Mark Pilgrim, I have removed the namespaced elements from my RSS feed.... [more]

Trackback from Ghost Cassette


Mark Pilgrim changed his RSS feed

Mark has two RSS feeds (both 2.0 flavor) one for his blog and another for comments. removed the funk from his RSS. removed the link element. removed the dc:date element. His dates were off by an hour. removed the rich content. removed the comment...

Excerpt from iBLOGthere4iM at

RSS, Items and Links

Arrrrrrgg! Right that's got that out of the way. There's some confusion about the proper use of Link in an item in an RSS feed. As a developer my approach to this is to look at a)the spec, b)examples and c)the market, ie what does everyone else do....

Excerpt from jbond's blog at at

Ah Yes ... The First Casualty of Echo Has Arrived and it is Anyone Who Uses an Aggregator and Reads Mark (or uses Feedster)

Ah Yes ... The First Casualty of Echo Has Arrived and it is Anyone Who Uses an Aggregator and Reads Mark (or uses Feedster) Well, well, well.  This really blows.  I just caught this over on Dive into Mark:  Update 2: I have removed...

Excerpt from The FuzzyStuff: aaaaFeedster at

Adina, take a look at NewsML. They've been through years of review and implementation.

VoiceXML models an entire user experience, including navigation.

Posted by Phil Wolff at


Further reading: The Lizard Brain of RSS, in which we learn that we've all been using <link> incorrectly for 4 years. There is no FAQ, in which we argue about #1. Leave RSS Alone, in which we learn that most aggregators don't support guid as a...

Excerpt from phil ringnalda dot com: Breaking the world of syndication: Comments at

Identifying Atom

Quote: And people wonder why RSS turned my hair gray. Source: Roger Cadenhead. Randy: Another misleading article on RSS and Atom. There's a history here. This is very similar to the presidential race. Bush carries on a positive campaign, while his...

Excerpt from RSS at

RSS has been damage by in-fighting among those who have developed it

Syndication feeds such as RSS and Atom have the power to automate the delivery of all forms of digital content. The word “content” can refer to weblog posts or MP3s, the U.S. President’s last speech or the photos of your last...

Excerpt from Category 4 Blog at

I think that you also should check out this blog because you will find there lots of tips on how to write scientific essay. please ta e a look at it sooner or later

Posted by Lisa Abrams at

Add your comment