Slashdot Mirror
Apple Breaks RSS with Photocasting
Barry Norton writes "VNUNet reports that the Photocasting feature in Apple's iPhoto application violates core XML and RSS standards. Perhaps the worst part is that, in many cases, this isn't even a case of 'embrace and extend', but just plain doing it wrong. Dave Winer, essentially the creator of RSS, says, 'It's pretty bad. There are lots of errors, the date formats are wrong, there are elements that are not in RSS that aren't in a namespace.'"
I know there are plenty of RSS Validation tools out there that will go to a website and tell you whether or not the RSS Feed is valid based on current standards but what about for applications?
What does Dave Winer (or anyone who works with RSS daily) recommend we use to validate applications and websites? What's the best tool to quickly and efficiently evaluate our work in parsing and assembling RSS?
I've used nifty tools like XML Spy for validating XML and XSD forms and I was wondering if there is an equivalent for RSS 1.0, RSS 2.0 and Atom 0.3 formats.
My work here is dung.
Not real surprising. I was all excited that iTunes had an XML export facility for the library, until I saw it.
I'd expected to apply some kind of transformation to the document to make it suit my needs, but this was tragic. It was painfully obvious that whoever wrote the export didn't even remotely "get" it. It was some horrid hodgepodge of tags all slapped together around what amounted to a CVS dump. It was well formed, basically useless as an XML document.
I'd have been happier is the export was a simple delimited file or even a binary dump, at least it would have been smaller.
RSS fubar? Yep, they still have the same people doing their XML. Let hope this makes them rethink that...
I happen to have RSS on the brain at the moment, since I just this week implemented RSS 2.0 for my personal webpage. The comments on the linked articles mostly go like this:
c asting-Hyperbole/
- It works for me!
- It doesn't matter that it works for you; it violates standards!
- But there are no standards for RSS!
- Are too!
and so on.
For a counterpoint, check out this blog entry:
http://www.intertwingly.net/blog/2006/01/18/Photo
The whole flap is quite a learning experience if you're interested in RSS.
Free, legal music for iTunes users.
Apple has always been more about making a big splash in the media with some technology than about releasing something solid and fully tested. This is the sort of thing that should have been found in beta testing, but then Apple's never been too big on doing that because it might spoil their "one more thing" at the next Steve Jobs keynote. Better to fix it after it's in the wild than risk a leak to the media. I'm not the only one questioning their quality control. There are lots of others. Just look at the mess they've made of font management in OS X. It's causing graphic designers no end of problems. The really bad part of this is that the kind of people who'll be using this application will be less-technical users who won't know why violating these standards is a bad thing and wouldn't be able to fix it if they did know. For a company that once had the best quality control and the best operating system, they've sure gone downhill. Sadly, Apple isn't learning the right lesson because their sales (thanks largely due to the iPod) are doing well and the Mac Faithful seem willing to live with the flaws just because "it's a Mac".
Nonsense. RSS doesn't have to be governed by a standards body for Apple's actions to be "wrong." The spec can be found at http://blogs.law.harvard.edu/tech/rss quite easily. And there's nothing stopping Apple from visiting http://feedvalidator.org/ to make sure their code works. They clearly didn't bother to do that.
This isn't Apple bashing either. Many of the people who are most upset about this, myself included, are diehard Apple users.
Apple screwed up photocasting, pure and simple. And they screwed up their podcasting spec too by releasing poorly designed specs (and I'm being generous here by calling their first attempt a "spec") and then changing things later. And they've made processing of some of their elements amazingly difficult. For instance, the itunes:keywords element can either be delimitted by commas or spaces. There's nothing in the xml itself to indicate for sure which you're dealing with, you just have to guess. Check if there's a comma present, if so, split by commas, otherwise, split by spaces. But what happens if they meant to use the single keyword "bad apple" instead of "bad", "apple"? There's no way to know for sure. The whole point of a spec is to avoid this kind of rediculous imprecision.
So yeah, Apple doesn't seem to have the first clue about generating valid RSS or XML any of that stuff. And all they had to do was ask. Secrecy is not always your best friend.