intertwingly

It’s just data

Photocasting Hyperbole

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.

For shame.  Why can’t they “Just” use XML, like everybody else does?

It turns out that they do.  Just like everybody else does.

http

I don’t know about you, but in my mind the “first thing about HTTP” is “HTTP GET”.  More specifically:

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 possible”.

For shame.

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 Conformance 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 RFC 3023.  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.

xml

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.

Unfortunately, it seems that they are in good company here.

rss

So, is the feed format Invalid?  Fairly bad?  Spectacularly bad?

It seems that many, if not most, feed readers can deal with photocasts already.  How can that be?

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 dates. 

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 Feed Parser.

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.

perspective

Clearly, being in good company doesn’t make it right, there certainly is room for improvement.  But lets put it in perspective...

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” format (Note: I’m 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 iPhoto?

The answer to the first question is largely yes, with issues that need to be worked.  But not until they find the “real feed”.

It seems that the “feed” that iPhoto prepares is not a feed at all, but rather a JavaScript application that determines 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 by everybody.

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.

Recommendations

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 sources.

What can be done about that?  Several things.