It's a point that's been discussed in other threads, as well.  One thing that is difficult to manage is the aggregation of feeds without standards.  Unfortunately, the strict enforcement of RSS v2.0 implementation is more for the aggregation rather than just the display of a single feed.  Still, I've got the same view about it being too strict, as most newsfeed sources will never all comply with the specs for any version of the RSS or Atom specs.  One of the more common errors is in the display of date of publication, which is not even a standard element between RSS v2.0, RSS v1.0 (RDF), and Atom feeds.  Also, the date formatting is totally out of whack for for a lot of feeds, even when somethings gives GMT as its' base, you cannot rely on the develper actually giving you that correctly.

With the apps I write for desktop, I just take this information without trying to validate it or use it for anything other than displaying it as given.  I find it easier to fashion a date for sorting, or caching, which I take from the time I first bring in the element.  It's not going to make a whole lot of difference in the presentation anyway IMHO. 

It's mostly a matter of lack of attention by developers writing the feed generators.  We see it in the DNN modules as well.  The whole point of specs is to keep folks from having to worry about issue with code that is supposed to be compliant.  Of course, that's not what we see in the real information world.  If auto makers disregarded safety specifications as much as developers, we'ld have pulled the offenders off the market.  Unfortunately, there is no similar enforcement in our IS world.

I know Peter is actively engaged in resolving the issue, and appreciates everyone's patience with the issue.  I think going into this update, most didn't realize the number of newsources that were not compliant.  If something says it's RSSv2.0 then it should be expected to be a valid feed.  There's the trouble, even larger news providers don't offer compliant RSS, so it's something the industry just avoids by coding around it.  In the end, that's probably what will have to be done in the module.

iwonder

I can not aggree more in relation to the standards and the purpose of the standards, boy we could do some pretty cool stuff if everyone feed us the same content! Unfortunately, in nearly all projects where external data is involved from multiple sources enforcing a standard is once of the most challenging tasks which is often given up to reduce project risk.

In the case of the Newsfeed module, i feel that usability is probably more important at this time rather than standards, some of the biggest feeds sources like news companies etc do not apply the standards.

It's funny your reference regarding auto makers was exactly what I was thinking when I created the post :)

I discovered the PubDate issue after my post when I finally attempted to use some DotNetNuke feeds :( also found that for example the DNN Annoucements feed was sorting from old to newest, therefore when using NewsFeeds the top 10 posts dated back to 2007, even when using IE display of the rss feed would not sort correctly, possibly because of the PubDate format.

I have seen in government projects where they have  tight requirement for various standards, however I have also seen them remove the task to test against the standards from the project plan so they never compare the results of the project against the demanded requirements. If the developer takes the wrong date then the problem lives on.

I aggree "right or wrong" the module may have to flex towards the current "norm" to satisfy the majority at this time, or have something like IE such as standards mode or relaxed mode?

Cheers

Craig