Mark Pilgrim: To sum up, the “photocasting”
feature centers around a single undocumented extension element in a
namespace that doesn’t need to be declared. iPhoto 6
doesn’t understand the first thing about HTTP, the first
thing about XML, or the first thing about RSS. It ignores features
of HTTP that Netscape 4 supported in 1996, and mis-implements
features of XML that Microsoft got right in 1997. It ignores 95% of
RSS and Atom and gets most of the remaining 5% wrong.
It turns out that they do. Just like everybody else
I don’t know about you, but in my mind the “first
thing about HTTP” is “HTTP GET”. More
GET / HTTP/1.0
Does iPhoto 6 get this right? Yup. Does it get all
required aspects of HTTP right? Nothing Mark says indicates
otherwise. So what does it get wrong?
Apparently, it doesn’t include some optional
headers that nothing in the RSS 2.0 spec references, and it
doesn’t automatically update the location in response to a
301, something the
spec says it “ought to”... “where
The situation is a bit better in Atom 1.0. The spec
doesn’t reference these headers and status codes, but there
is a set of
Tests which do.
But there is one thing that they do get wrong that I’m
surprised that Mark didn’t mention, particularly as the feed
validator picks up on it. They get the mime type wrong.
application/octet-stream is not defined by
This is an area of confusion in RSS, again something that Atom
makes a bit clearer.
I suspect that this is a result of the (somewhat misguided)
attempt to be helpful. More on that in a minute.
I don’t know about you, but “the first thing about
XML” is well-formedness. Are the feeds that they
produce well formed? Yes. Kudos. Truth be told,
not everybody consistently meet this bar.
And with one exception, they seem to be able to consume all well
formed XML correctly. That exception has to do with
namespaces, something that is technically optional at the XML
layer, but explicitly called out in the RSS spec, so it really
should be done right.
It seems that at the feed level, there are two basic
problems. Both turn out to be fairly minor.
The first is that three optional elements have dates in ISO 8601
format instead of the modified RFC 822 format that RSS 2.0
prefers. Robust clients have long since come to realize that
the RFC 822 format is troublesome, US-centric, and
deprecated for new
formats. Many have come to handle ISO formatted
The other is that they include one (or
three, depending on how you count) extra elements that have not
been defined in the RSS 2.0 spec. Once again, robust
consumers have long since come to expect this.
And, once again, the situation is a bit better in Atom.
The one undisputed “extra” element is actually present
in Atom, in fact it is required. The other two turn out to be valid
extensions in Atom. And the date formats are ISO 8601, of
which Atom’s dates are a constrained subset. With a few
minor changes, they would conform.
Net: if the unexpected elements and optional dates are ignored,
the rest of the feed can be correctly consumed. Any many
consumers do. Including Mark’s
Oh, and if they ignore features of RSS and Atom that don’t
apply to their application? That’s not a bug,
that’s a feature.
Clearly, being in good company doesn’t make it right,
there certainly is room for improvement. But lets put it in
If they had invented a proprietary format, we wouldn’t be
having this discussion. (Instead we would be having
another one, but lets keep on track here).
But there is only one reason to pick a “standard”
not going to quibble too much here), and that reason is
interoperability. Do they produce feeds that can be consumed
by others? Can others produce feeds that can be consumed by
The answer to the first question is largely yes, with issues
that need to be worked. But not until they find the
It seems that the “feed” that iPhoto prepares is not
if you support the format. To be quite blunt, this is at best
misguided. But, as
Phil Ringnalda noted, if this data had been correctly returned
with a text/html mime type and included autodiscovery, many feed
consumers would have automatically found the correct feed.
Even so, all this is entirely unnecessary... if the feed were 100%
valid, there would be no reason why it couldn’t be consumed
The answer to the second question is not very effectively
without the documentation that Mark had to reverse engineer.
And those are really the two biggest issues: lack of
documentation, and a somewhat distasteful and paternalistic attempt
to be helpful in a way that ironically results in exactly the
opposite results that one would desire — assuming that
interoperability is, in fact, the goal.
Let’s face it, the Internet is a rough place. If you
are secretive and don’t meet up to the all the expectations
of the people out there (some documented and many not), then you
will be virtually burned in effigy by a lot of respected
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.
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 ("http://www.apple.com/ilife/wallpapers", “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. As a result, iTunes worked out of the box with pretty much every RSS-based podcasting feed on day 1. iPhoto, on the other hand, absolutely requires the (undocumented) apple-wallpapers:image element, and it really strongly recommends the PhotoDate element (for sorting). If they’re missing, you would think iPhoto could just use the enclosure element, or the link element, or even scrape the URL out of the img tag in the description to find the photo. It could use pubDate or atom:published for the photo date. But no, there’s no fallback. It’s apple-wallpapers:image or bust. 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.
Apple’s latest software bundle wraps RSS together with photo-publishing and they call it “Photocasting”. Reasonable enough. Dave Winer and Kevin Yank have pointed out that there are some real problems with the RSS. So Mark Pilgrim did a deep-dive...
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.
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]
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.
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”.
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).
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.
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.
As a result, iTunes worked out of the box with pretty much every RSS-based podcasting feed on day 1. iPhoto, on the other hand, absolutely requires the (undocumented) apple-wallpapers:image element, and it really strongly recommends the PhotoDate element (for sorting). If they’re missing, you would think iPhoto could just use the enclosure element, or the link element, or even scrape the URL out of the img tag in the description to find the photo. It could use pubDate or atom:published for the photo date. But no, there’s no fallback. It’s apple-wallpapers:image or bust.
Reportedly, flickr feeds work in iPhoto. Are you perhaps unaware?
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!”
There’s a long post (and a lot of good comments) over on Sam Ruby’s blog about the various problems with Apple’s new PhotoCast RSS Module. I find that I’m having a very hard time getting worked up about this. Sure, Apple could have done things...
Depressing as usual: "To sum up, the “photocasting” feature centers around a single undocumented extension element in a namespace that doesn’t need to be declared. iPhoto 6 doesn’t understand the first thing about HTTP, the...
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.
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.
I’m befuddled by the idea that they’re valid in Atom 1.0.
To which Tim replied:
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.
I’m going to have to side with Mark on this one ... there are just too many examples of Apple not getting it. It’s time they got it. I sure miss Mark’s blog, but his mailing list posts almost make up for it! Source: Sam Ruby: Photocasting Hyperbole......
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.
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.
I’m going to have to side with Mark on this one ... there are just too many examples of Apple not getting it. It’s time they got it. I sure miss Mark’s blog, but his mailing list posts almost make up for it! Source: Sam Ruby: Photocasting Hyperbole...
[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...
It’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....
DDJ>The Myth of “Seven, Plus or Minus 2″ - in other words, use common sense. Why Ajax Is So Disruptive (web2.wsj2.com) About that DOJ Request (by Jeremy Zawodny) FuzzyBlog - Respond Quickly to Each and Every Comment - of course, doing...
Apart 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...
Mark Pilgrim: Unofficial documentation of iPhoto 6.0 photocasting feeds
Mark 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...
masklinn on Follow-up: OGG has now been removed from the HTML5 spec.
But Safari’s track records are pretty good, right? It’s not bad for the simple reason that it had to be good. It had no chance of becoming a major player in the market if it’d done any less than Firefox and Opera (and really, it’s only with