Don caves

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! :-)

10 thoughts on “Don caves

  1. Craig Andera

    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.

    Reply
  2. Greg Reinacker

    I posted a sample feed [removed], 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.

    Reply
  3. Don Box

    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.

    Reply
  4. RSS and the RESTian Dilema

    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]

    Reply

Leave a Reply