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...
Huh? is there even an RSS standard?
The war with islam is a war on the beast
The war on terror is a war for peace
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.
Do you thing the world will change its way of handling RSS due to Apples implementation of photocasting? I guess some readers will accept Apples RSS misbehavior as an alternative to be compatible, like web browsers accept shitty HTML pages. But most will not. If they even care (Apple is still a dwarf in the RSS world), they will simply wait if this will not be fixed in a couple of weeks. Apples own RSS reader is Safari, used by 2%-3% of all surfers. Not really something you worry about being picked up by users as an alternative to your RSS reader temporarily without photocasting compatibility.
memomo: free web based language trainer DE-EN-ES-FR-IT
Dave Winer is appropriately named; he has a grudge against lots of people. Having worked in support for a an ISP who formerly hosted his site, I can vouch first-hand for his temper and irrationality in many "tech" issues.
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.
since Apple prides itself on embracing open standards when possible, why not simply report these as bugs and presume they will be fixed
Maybe they will be.
And maybe Apple will finally properly implement the ID3V2 tag standards -- they use a non-compliant tag (TCMP is not a valid ID3V2 tag, and they use it on all "compilation" albums; there are many other tags that could be used instead and still comply with the standard) in all of their implementations and their ID3V2.4 implementation is completely fucked.
And yes, they've been asked to fix this many times and have ignored it.
Yeah, I know the ID3V2 standards are rather poorly written in some places, but Apple's implementation (at least of 2.4) is so bad it's as if they didn't even try.
So here it is not surprising that he has chosen to attack Winer rather than evaluate the merit of Winer's statements.
Oh yeah, if you are reading Dave--thanks for RSS and OPML :-)
slashsearch.org - slashdot search. powered by google.
It isn't something that should be fixed in the next patch, because it wasn't something that should have gotten past QA.
That's a pretty harsh assesment
[Fuck Beta]
o0t!
Welcome to the world of engineering! Remember, this isn't Computer Science we're talking about, where most everything is peer-reviewed and works nicely. In the arena of real-world software design, compatibility with your competitor or even with your users is often a massive pain in the ass. But such difficulties are unavoidable, and part of engineering, be it civil, mechanical, or software.
You won't hear a civil engineer bitch about how annoying earthquakes are, and how much easier their life would be if they didn't have to take excessive wind gusts into account when designing structures. They just shut up and deal with the problems that they're faced with. Software engineers should do the same when it comes to the difficulties they face when creating a product.
Standards help keep everyone near the same page, but they never coordinate everyone's products or actions perfectly. The developers of software must make a tradeoff between standards compliance and market share. Any browser or RSS reader, for instance, which doesn't accept what the others accept will often become irrelevant in the eyes of the users.
Rejecting all invalid, yet interpretable, input is not a wise idea. If data has an extra-standard interpretation by some other implementation, then it is not "garbage". As such, other implementations worried about their marketshare have no choice but to add similar support. The "solution" of barfing out on such data will only decrease a products marketshare, making it irrelevant in the long run.
Cyric Zndovzny at your service.
What a ridiculous analogy. You can't stop earthquakes from happening easily. But you can stop your software from emitting malformed documents easily.
That's why it's so important that all XML parsers throw out malformed documents. Even Apple's.
XML doesn't demand that you reject invalid documents. Only malformed documents. And it's a very good idea if everybody does it. In particular, it's a hell of a lot better than having to deal with the "earthquakes" of nonsensical documents.
Bogtha Bogtha Bogtha