text: 
  Graham - not quite.
  HTTP - that’s 100% iPhoto’s interpretation.
  XML - I talked about both sides. And with one exception (dealing with namespaces), they can handle all types of well-formed feeds. They just happen to be a bit more liberal than that, something I can’t imagine Mark taking offense with.
  RSS - this clearly affects production and consumption. They produce some extra data, some of it in not quite the right format, and on the consumption side they don’t rely on this data. This seems to be a case where they tried to do the right thing, but fell a little short, and in ways that didn’t affect their application.
  Perspective - I covered both sides.
  Recommendation - Validation/Conformance Testing are each on one side, the rest is generic to both.Posted by Sam Ruby at
  Sam Ruby: Photocasting Hyperbole[link]...
  Excerpt from del.icio.us/miyagawa at
  Sam Ruby: Fair and Balanced.
  Posted by Robert Sayre at
  While this new perspective is undoubtedly quite reasonable, I have to say I prefer the effigy burning. Nobody likes being burned in effigy, and one can always hope they’ll mend their ways...
  Posted by Bob Aman at
  Wow. Such a convoluted response, it’s hard to know where to start. Or whether it’s even worth my time. Reminds me of this, but never mind.
  “Does it get all required aspects of HTTP right?” Oh yeah, that should be the gold standard of an aggregator with a potential customer base in the millions. Come on, Sam, we’ve all been bitching^H^H^H^H^H^H^H^Heducating people about ETag support since 2002. Ditto gzip since 2002. Permanent redirects and other HTTP status codes and a whole bunch of test cases since 2003. It’s now 2006. At what point are we allowed to say that “GET /” just isn’t good enough?
  Your next point about XML well-formedness is self-contradictory. In one breath you note that the .Mac feeds are served with a non-XML content type, and in the next breath you’re claiming they’re well-formed XML. You can’t have it both ways, no matter how loudly and how often Joshua Allen and Dare Obasanjo proclaim otherwise.
  As for namespace support, from the evidence I’ve collected, it is obvious to me that iPhoto is using a non-namespace-aware XML parser. This explains why the prefix name matters so much and the namespace declaration matters not at all. They’re simply looking for an element called “apple-wallpapers:image”, not an element represented by the tuple ("", “image"). Note that this (undocumented) namespaced-but-not-really element is required by iPhoto, which effectively forces all publishers who wish to interoperate to understand iPhoto’s bizarre parsing quirks. "Everybody else has vaguely similar bugs” is not a justification. This is, for all intents and purposes, a proprietary format. It just happens to have angle brackets.
  I don’t much care about the invalid channel-level guid, or even the wacky invalid photoDate/cropDate. I’m only slightly peeved that they have invented yet another date format for PhotoDate, although it does mean I’ll need to write more test cases. I already handle 28 different date formats, including Korean, Greek, and Hungarian, but I ain’t never seen a feed with a “number of days since the start of what everyone but the pedants agree is the new millenium” date before. Hungarian? Yeah, I can do Hungarian. If Apple had gone with Hungarian dates, I wouldn’t have to write a single test case. PhotoDate? At least 3.
  But I can’t get too worked up about any of that. What really galls me is the lack of fallback behavior. iTunes' feed parsing was spectacularly bad, but at least it didn’t require any of the iTunes extension elements for basic functionality. If they were missing, iTunes would fall back to the appropriate core RSS elements for titles, descriptions, keywords, etc.. PhotoDate or bust, wacky pedant-hostile date format and all.
  This is what I meant when I said that iPhoto ignores 95% of RSS and Atom. Even if you accept the shaky premise that they just had to invent their own namespace because this information is just So Damn Special, why couldn’t they fall back to core elements if their extensions were missing? And then document the mapping (something that’s still missing from the iTunes specs, BTW). Or, better yet, Stop Inventing Random Undocumented Crap in the first place. But no, it’s apple-wallpapers:image or nothing. That’s a big deal, no matter how much you try to obscure it or trivialize it.. Here’s a hint: if it takes a user-agent sniffer and 50 lines of JavaScript to load a URL, you’re swimming against the current.Posted by Mark at
  Photo RSS, Sort Of...
  Excerpt from ongoing at
  Mark, thanks for the dailykos link. Funniest thing I’ve read all day.
  /OT
  So the question is, why does Apple not get this stuff right? It’s not like they can’t afford to hire someone to do a double check of all these things before they ship.Posted by jacob at
  From a techie viewpoint, Apple is breaking standards or at least trying to create their own standard, which sucks.
  From a marketing viewpoint, if iPhoto feeds require iPhoto to view them, this may mean more people will have to buy a Mac. Which may be a perfectly plausible reason for Apple going the Microsoft way “embracing and extending” web standards.
  Apart from that, every RSS aggregator application (or website) on Mac, Windows or Linux will at some time in 2006 be updated to boast the line “Now with iPhoto support”. Which means more attention for Apple.
  I am not saying the ends justify the means and anyone can go free breaking web standards. I am just saying Apple may be having a different agenda from dev/tech people.Posted by Pliep at
  To me, this simply looks like a “Version 1” implementation of support for some standards. I don’t see anything sinister here; rather, what I see is a team of developers trying to ship a working product to a deadline. For anyone interested, there’s more on my blog entry - “Apple’s Photocasting. First Make It Work. Then Make It Work Better” @ [link]
  Posted by Simon Brocklehurst at
  Am I mistaken in believing this thing is serving up JPEGs? In which case, what use would gzip compression be?
  Posted by Jon Dowland at
  Nobody likes being burned in effigy, and one can always hope they’ll mend their ways
  I’ve seen no evidence that that has been effective.
  At what point are we allowed to say that “GET /” just isn’t good enough?
  Remember, the things you write on your weblog are not spec test. What you will find on weblogs is a bunch of contradictory and incomplete opinions complete with cat pictures. What the Apples of the world really need is things like this to be completed and published.
  Actually, I feel like the straight man in that piece of entertaining piece of Kos’ sophistry. I do believe that mime types are important, in fact, I’m the one that added that to this discussion. What I didn’t say was that iPhoto 6 doesn’t understand the first thing about HTTP. It wasn’t that long ago that all of us were morons, and you know, somehow the web survived us and taught us.
  It’s not like they can’t afford to hire someone to do a double check of all these things before they ship.
  Is the Feed Validator really so hard to use that it takes hiring somebody to run it? Come on.
  I am just saying Apple may be having a different agenda from dev/tech people.
  If so, they should be building their own protocols. Misusing infrastructure which others depend on creates more work for everybody - including Apple. Just to be clear, I’m in complete agreement with Mark’s substantive content. I just think that a wee bit less hyperbole, and a bit more constructive suggestions needed to be injected into this conversation.
  what I see is a team of developers trying to ship a working product to a deadline.
  ... virtually none of which are communicating with the outside world. A lot of feedback that Mark and others have been providing has not only has been unheeded, much of it is virtually unacknowledged. And, no, I don’t count the “I got your feedback, but I’m off at some conference and will get back to you” (but never do) types of responses.
  Am I mistaken in believing this thing is serving up JPEGs? In which case, what use would gzip compression be?
  From my understanding based on Mark’s analysis (I don’t own a Mac), ultimately, an image will be requested once. However before that, and presumably many times after that, your feed will be requested. What things like ETAGs provide is a way to say “if it hasn’t changed, don’t bother sending it again”.Posted by Sam Ruby at
  They view the web as an annoyingly inadequate infrastructure on which to build their latest proprietary network, in much the same way that old-school web designers view HTML as an annoyingly inadequate page layout language.
  Yes! Someone (or somethrong, really) over there seriously needs to read Motherhood and Apple Pie (in all its serendipitous titular irony).Posted by Aristotle Pagaltzis at
  Sam wrote: A lot of feedback that Mark and others have been providing has not only has been unheeded, much of it is virtually unacknowledged.
  Well, my job certainly isn’t to defend Apple or their developers; there’s never any excuse for rudeness. And not acknowledging (polite) feedback counts as rude in my book.
  Having said that, sometimes people really are overstretched. I’m sure most of us have, on occasion, let the odd e-mail slip through the net without a considered response.Posted by Simon Brocklehurst at
  What the Apples of the world really need is things like this to be completed and published.
  The Atom implementation guide is called feedparser documentation. You know as well as I do why such a guide will never be published by the Atompub working group.Posted by Mark at
  The Atom implementation guide is called feedparser documentation
  All it needs now is a “Beware of the Leopard” sign.
  You know as well as I do why such a guide will never be published by the Atompub working group.
  First of all, I never said
  all conservatives are racists published by the Atompub working group.
  First of all, I never said published by the Atompub working group.
  Make it an individual submission with the goal of becoming BCP, since that is exactly what it is. Submit it directly to the Area Director and we’ll dogpile it. Alternatively, submit it as a W3C Note.Posted by Robert Sayre at
  It wasn’t that long ago that all of us were morons, and you know, somehow the web survived us and taught us.
  Indeed, and the web will survive this too. It’s the “and teach us” part that I’m less sure about. I understand that every company larger than 10 people is a really just a sprawling suburban landscape of smaller companies that don’t talk to each other, but didn’t anyone on the iPhoto development team learn anything from the iTunes podcasting disaster? (My best-guess answer: no. Apple treated it as a PR problem and solved it with a PR mailing list, cleverly disguised as developers mailing list. Ha ha, the joke’s on us.)
  All it needs now is a “Beware of the Leopard” sign.
  And yet, amazingly, most developers who need to manage to find it anyway. If I honestly thought that any of the people who need to read it would read it in a different venue, medium, format, or tone, I would make that happen. (On an unrelated note, I quickly searched for such a graphic to add to the feedparser.org home page, but the search results are disturbing.)
  BTW, their .Mac feeds don’t validate either (and I mean before you had that fight with Rogers). feedvalidator.org is the #1 result for “feed validator”, “rss validator”, and “rss validation”. Perhaps you need to teach Apple’s development team how to use Google? Or perhaps the problem is that, as I stated earlier, it never occurred to them that there were publicly available resources that could help them, so I don’t think renaming the feedparser docs to “Official RSS and Atom Implementation Guide — Hey Buddy, You Really Need To Read This Before Releasing More Undocumented Crap” is going to help.Posted by Mark at
  Sam, to quote the “moron” link, “The second faction of morons work from examples, ship code, and get yelled at... Virtually every useful tutorial in the world was written by a moron-turned-expert.”
  I will continue to hope, as frankly, I am one of those morons who got yelled at, and I’ve been mending my ways. So yeah, it can happen.
  I also don’t don’t buy the “embrace and extend” analogy.
  Hanlon’s Razor:
  Posted by Bob Aman atPosted by Bob Aman at
  Never attribute to malice that which is adequately explained by stupidity.
  Mark, it’s comments like yours that keep that mailing list from being a developer’s mailing list. You’ve set the tenor solidly at “flamewar”. No engineer is going to want to join that conversation, because it’s quite clear that you are going to jump all over anything that is said. At that point it is a pr problem. So good job there. Apple’s other developer mailing lists are, in fact, full of developers.
  Posted by john at
  Mark,.
  Reportedly, flickr feeds work in iPhoto. Are you perhaps unaware?Posted by john at
  No engineer is going to want to join that conversation,
  I agree that the tenor of the conversation is a problem on that list, but it’s not the most serious problem. The comparison with other Apple mailing lists is interesting. When you bring up an issue on say, webkit-dev, you’re very likely to hear back from an engineer saying something like “oh yeah, that’s a bug, it’s in the tracker now. (bug NNNNNN)”
  On syndication-dev, bug reports get a response from a project manager saying “thanks for your questions!”Posted by Robert Sayre at
  it’s comments like yours that keep that mailing list from being a developer’s mailing list.
  You mean comments like these?
  Which got me nothing but this:
  We can’t comment or commit to specific product features before they are released. Thank you for your understanding.
  So yeah, it’s obviously entirely my fault that syndication-dev isn’t just overflowing with developers.Posted by Mark at
  Az Apple RSS majomkolonia #2Elozmenyek: zokszigen: Az Apple RSS majomkolonia, Mark Pilgrim leleplezi az Apple idiotizmusat, sonic irja: Azért érdemes elolvasni ezt is: [link]......
  Excerpt from zokszigen at
  XML KerfufflesThere...
  Excerpt from Smalltalk Tidbits, Industry Rants at
  BTW, their .Mac feeds don’t validate either (and I mean before you had that fight with Rogers).
  I’m a bit surprised to see that discussion described as a fight. That wasn’t my intent; I was trying to figure out whether non-namespaced elements are properly invalid in RSS 2.0. (I know they’re invalid by my reading of the spec — I’m just not sure if that’s a good thing.)
  I’m befuddled by the idea that they’re valid in Atom 1.0. If an Atom proponent could explain why that is, I’d love to hear it.Posted by Rogers Cadenhead at
  Correction: ... whether non-namespaced elements in a namespaced element are properly invalid.
  Posted by Rogers Cadenhead at
  RFC4287, 6.1:
  This specification describes Atom’s XML markup vocabulary. Markup
  from other vocabularies ("foreign markup") can be used in an Atom
  Document. Note that the atom:content element is designed to support
  the inclusion of arbitrary foreign markup.
  Anything that’s not in the Atom namespace is clearly foreign markup. Something that has no namespace isn’t in the Atom namespace. This is why being in a namespace is an advantage.Posted by Tim Bray at
  The Problem with iPhoto... [more]
  Trackback from Eighty-Twenty at
  Rogers said:
  I’m befuddled by the idea that they’re valid in Atom 1.0.
  To which Tim replied:
  RFC4287, 6.1:
  What Tim said. I was actually researching this a few hours ago and came to the same conclusion, and then didn’t get a chance to post it until now. I had never actually read that part of the spec before, and was pleasantly surprised to find that it clearly and unambiguously covered this problem. (For the record, Rogers has convinced me that the RSS spec clearly and unambiguously covers this problem too. “A RSS feed may contain elements not described on this page, only if those elements are defined in a namespace” is pretty clear, and it doesn’t make exceptions for non-namespaced descendants of namespaced elements.)
  So Atom 1.0 “owns” all elements in the Atom namespace, while RSS 2.0 “owns” all non-namespaced elements in an RSS document. As a general rule of thumb, I would say that extensions should live entirely in their own namespace, to maximize compatibility and minimize confusion. But since Atom itself lives entirely in its own namespace, Apple has inadvertently designed an extension that is valid in Atom but not RSS. And then embedded it in RSS anyway.
  Don’t worry though; Sam will no doubt assure us that this isn’t the first thing developers should know about designing an RSS extension. Maybe the second or third thing — I would venture that it’s definitely in the top 5 ("give us some fucking documentation" is probably right up there too) — but let us not venture into hyperbole by claiming that Apple doesn’t know the first thing about designing an RSS extension.Posted by Mark at
  Oh, man. What a trainwreck.
  Apple Breaks RSS with PhotocastingPosted by Robert Sayre...... [more]
  Trackback from Dancing About Architecture at
  Mark attributed his article on a group of RSS dignitaries. WTF? Name your source. Are they his friends who he calls dignitaries?
  Or will he get shot if he names them.Posted by a Journalist at
  I just wanted to comment on the above comment:
  And with one exception (dealing with namespaces), they can handle all types of well-formed feeds. They just happen to be a bit more liberal than that, something I can’t imagine Mark taking offense with.
  It may not seem like a bad thing that they happen to accept malformed XML, but as a large market share product, I think it is extremely important that they enforce standards now. Do you remember a few years ago when about a quarter of the pages on the internet wouldn’t work in Firefox? This is because Internet Explorer accepted malformed HTML pages (and still does), and many developers would only test against the de facto standard browser. This made it extremely hard for a 3rd-party browser to break into the mass market without breaking the standard in exactly the same ways that Microsoft had.Posted by Infomofo at
  In December, Apple updated the iTunes Podcast technical specifications. Given everything else though, maybe it’s still not such a good sign...
  Posted by Jay Fienberg at
  trainwreck
  I don’t know why we don’t call all forms of online publishing Telephone.
  (Meta: blockquote passes through, but blockquote cite="..." doesn’t.)Posted by Phil Ringnalda at
  Mark attributed his article on a group of RSS dignitaries.
  Nope.
  $ curl -s | grep -i dignitaries | wc -w 0
  Perhaps you are are referring to the Tom Sanders article where he referred to Mark Pilgrim as an RSS dignitary?Posted by Sam Ruby at
  Apple NOT "cheating on standard"An earlier link claimed Apple’s photocasting was not adhering to standards and got RSS “95% wrong.” Here’s the truth....
  Excerpt from diggdot.us at
  I enjoyed all of the comments.. and I think Apple should adhere to a common standard... when one is set in stone. THe bigger Question though is privacy.. Hold your cursor over someones name after the ‘Posted By’ and a nice tool tip comes up with their host that can easily resolve into an IP address for most of them. That concerns me.. if there are any people with nefarious intentions out there reading these comments.
  Posted by one1step1...
  Excerpt from Dancing About Architecture (Full Content) at
  Links for 2006-01-21 [del.icio.us][The Bible] debate goes to kids' TV Kid’s show “Nick News” to air a show on The Bible vs. Science. Sadly, no Flying Speaghetti Monster. Poor FSM! Privacy experts condemn subpoena of Google "Attorney General Alberto Gonzales rejected...
  Excerpt from Cote's Drunk & Retired at
  links for 2006-01-24Achewood - January 23, 2006 “I… I’m afraid I don’t understand. Does that mean you don’t eat cheese?” (tags: comics funny) [...]...
  Excerpt from 0xDECAFBAD at
  Feed landOn feed crap....
  Excerpt from Anne’s Weblog about Markup & Style at
  Photocasting nothing new, move alongIt’s been said over and over, but there seems to be some confusion. Let’s see if I can clear the air. Kudos to Steve and his team at Apple for ‘photocasting’. It’s a great name, I wish we’d thought of it....
  Excerpt from smugblog: Don MacAskill at
  Around the web...
  Excerpt from alexking.org: Blog at
  Greed trumps thinking differentlyApart from another dumb name from Apple (“MacBook Pro”), the underwhelming announcements in the most recent MacWorld keynote hid a really cool idea that could have changed how people used computers, had it not been saddled with an...
  Excerpt from Asteroid at
  Mark Pilgrim: Unofficial documentation of iPhoto 6.0 photocasting feedsMark Pilgrim: Unofficial documentation of iPhoto 6.0 photocasting feeds on the Apple syndication-dev mailing list. He says:To sum up, the “photocasting” feature centers around a singleundocumented extension element in a namespace that doesn’t need...
  Excerpt from Irreality News at
  Oh, good griefI’m so tired of being right all the time. It was fun for a while, but now it’s just depressing....
  Excerpt from dive into mark at
  Sam, Mark’s comments focused on iPhoto’s interpretation of RSS feeds. You commented almost exclusively on .Mac’s generation of RSS feeds. That’s why there’s such a difference in opinion here.
  Posted by Graham Parks at