--- In rss-public@yahoogroups.com, "Randy Morin" <randy@...> wrote:
> There's simply too much politics involve in our current choice. A
> more neutral choice would better fit going forward.
I agree (unfortunately), but I think we can handle it better by
installing a copy of the Feed Validator on our server. That will also
give us access to some useful data on the most common validation errors.
I may need some help from people with experience setting up
Python-based web apps.
This is looking great. Thanks a lot for your great work Rogers. Randy ... date ... description ... from ... representing ... compatibility ... numbering. ... ...
I think this is looking really good, but I have still some issues with the Character Data recommendations. It recommends hexadecimal characters references as...
I would stick to one recommendation for publishers, but describe both common for readers. BTW, I'm not sure what you mean by form of double encoding. I think...
... Getting single encoding to work everywhere seems like a far more attainable goal, especially since any publisher who wants to work in IE and Firefox will...
... Furthermore on the subject of double *decoding*, for the second decoding (from the output of the XML parser), is the de-facto standard to treat it like...
OK, we are on the same page. For me there are countless ways of encoding stuff. If I were interpreting RSS, then... <title>AT&amp;T</title> ...translates...
... This same argument was made over a year ago, and yet nothing seems to have changed in all that time. There are still high-profile feeds double encoding ...
... I can't speak for other aggregator authors, but in my case this is a deliberate choice. Regardless of what the spec says, interpreting the above example as...
100% agree that making things work should be your priority as a developer. So, let's point out that some have chosen to double-encode <title> and that it is...
As a developer on the SimplePie project (an OSS RSS/Atom parser for PHP), my understanding is that if data is wrapped in CDATA tags, we leave it alone...
Ryan, You are exactly correct. In the spec [http://www.rssboard.org/rss- specification#hrelementsOfLtitemgt] it says, "the description contains the text...
... I guess the only way for a developer to opt out of the quantum superspecification idiocy would be to make this a user- configurable feed-local option....
... I agree (unfortunately), but I think we can handle it better by installing a copy of the Feed Validator on our server. That will also give us access to...
If you are willing, then I'd agree to it. And thanks for all the great work on the site, Randy Charles Morin http://www.therssweblog.com ... errors....
... The problem is that we're telling feed producers that they need to *single* encode titles at the same time as we're telling (or should be telling) feed ...
... Using hexadecimal character references, correct? ... If you could draft some suggested text for this, or write another article on your blog like the last...
... The problem with that (other than that most users would never find the option) is that the sensible default (IMHO) would be to double-decode, the result of...
... That version you cited doesn't have it. <http:// feedparser.googlecode.com/svn/trunk/feedparser/feedparser.py>, however, does. - Geoffrey Sneddon...
... Exactly that is why it's not sensible in my book. Silent failure is much harder for the user to notice. With obvious failure, they get the chance to notice...
... But that's exactly the issue -- the end-user shouldn't HAVE to notice. It's almost as if we want to punish the end-user for the publisher's mistake. They...
... RSS is the wrong format for that. It gives you exactly two choices: 1. Inconvenience the user (garbage displayed) 2. Do a disservice to the user (silent...
... The second decoding is HTML, since that is essentially what it is. When a feed is double-encoded, it's usually because people have taken their HTML (with...