Don caves
March 28th, 2003 by gregr
Don Box writes:
Due to popular demand, my RSS/2.0 feed will soon support <content:encoded>, which will allow users of off-line readers (e.g., NewsGator, NewsGator, and NewsGator) to read my feeds without being connected.
Heh…NewsGator users aren’t a quiet bunch! :-)
This entry was posted on Friday, March 28th, 2003 at 9:41 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
March 28th, 2003 at 1:01 pm
I’m happy to report that I complained directly to Don, due exactly to the fact that I use NewsGator and have become completely hooked on the way it lets me read RSS feeds.
March 28th, 2003 at 2:35 pm
Way to go Craig!
March 29th, 2003 at 11:18 am
See http://www.intertwingly.net/blog/1298.html
Sam’s right.
Look for by monday (and to disappear…).
DB
March 29th, 2003 at 11:18 am
See http://www.intertwingly.net/blog/1298.html
Sam’s right.
Look for xhtml:body by monday (and content:encoded to disappear…).
DB
March 29th, 2003 at 12:17 pm
I posted a sample feed, since I couldn’t find an example in the wild. Does this look like what you’re thinking? We’re about 2 days past a code freeze for 1.1, but this is such a trivial change, I’m thinking about checking it in and restarting the test suite.
March 29th, 2003 at 4:40 pm
Craig just reported a bug in NewsGator to me.
My feed (as it sits this weekend) is spitting out content:encoded elements that contain CDATA escaped HTML classic.
The content in my feed correctly expands the nbsp entity reference to a character reference (whose value is 0xA0). Look for the in the text.
According to Craig, the character reference causes NewsGator to puke. Sounds like perhaps you aren’t handling character references when you crack the embedded HTML.
BTW, the xhtml:body-based feed will also have the character reference - it’s totally kosher and the only way to get it to work given the modularity limitations of DTDs.
March 29th, 2003 at 4:57 pm
Hmm, not sure what you’re referring to. We can deal with entity references as well as   character references. Or did I miss the point?
March 29th, 2003 at 8:49 pm
There we where thinking we had some agreement on the RSS format and had achieved some convergence and stability at the 2.0 level, then this happens! So, what have Don and Sam created? Is it RSS v4.0, or RSS 2.0+xhtml:body, or what? - and how exactly do we work out what it is and how to process it? The problem this change demonstrates is what I call the “RESTian Dilema” - we have no way to link the data we get back with the _exact_ details of the format of that data. My computer does not know that Don’s RSS 2.0 feed uses xhtml:body while my RSS 2.0 feed currently uses content:encoded. From the HTTP content type we know it is XML in RSS format plus the document element in the XML data tells us it is RSS v2.0, but nothing tells us we need to look for the full item entries in xhtml:body elements rather than content:encoded elements. Sure, we can work in a degraded state (ie. back to RSS v0.91 levels!), but that’s not the point here. I completely understand that both xhtml:body and content:encoded fragments are valid extensions to the base RSS v2.0 core format, and this is a totally appropriate use of XML’s (and RSS’s) extensibility through namespaces facilities. However the question still remains of how do we version XML DOCUMENT FORMATS as a whole, rather than just individual schemas / namespaces? I think that when we are talking about standardized payload document formats (like RSS needs to be, IMHO), we need to start using some form of “meta-schemas” that define an exact _fixed_ and _versioned_ format for the contents. Obviously XML Schema language is more than able to handle this, but we need it here at the “meta-schema” level by defining the format for this XML data is ( rss-v2.0 + dc + xhtml:body ) rather than ( rss-v2.0 + content:encoded ) or ( rss-v0.91 ) I am not necessarily saying we should prohibit further extensibility in RSS feeds, just that for stable / standardized (and fully processable) payload formats we need to consider VERSIONED EXTENSIBILITY. This is the next level of challenge for versioning with XML I believe, and was exactly the point I was making in my posts last week about needing to standardize the RSS format. The impact of this change is obvious - Greg Reinacker has to update NewsGator to support grabbing the full item from the xhtml:body elements as well as the current content:encoded elements, then he needs to push an updated version out to all his customers (including me) so we can read Don’s full blog entries while offline. This is not in and or itself a problem of course, but the fact that we still don’t have a totally stable and agreed definition of the RSS format *IS*. A one-off change we can probably live with, but the speed that Sam and Don iterate at ? ….. well, you know the answer already don’t you? RSS is…[more]
March 31st, 2003 at 11:37 am
So, it looks like what NewsGator was puking on was an older version of Don’s feed (http://www.gotdotnet.com/team/dbox/rssex.aspx). It still seems to be the , but I’m not sure about the exact details. I’ve given Greg more detailed information - hopefully he’ll figure out what the issue is - whether it’s NewsGator or something else.
March 31st, 2003 at 11:48 am
That feed is dead, and actually returns a HTML error page. Since that isn’t valid RSS, you get an error.