Apple “photocasting” Mac only, uses invalid RSS

(via Dave Winer) Apple’s newly-released iPhoto 6 does an admirable job of making it easy for its users to publish feeds of their photos from their desktop. When Steve Jobs announced the product, he cited its use of “industry standard” RSS technology to make this posssible.

This all sounds great until you try to visit a photocasting feed in a browser other than Safari, or subscribe using a feed reader other than NetNewsWire. The site detects that you’re not using a photocast-capable client and displays an HTML page asking you to use Safari instead.

The error page in question also provides a direct link to the RSS feed for the photocast. If you know your XML, check out this browser-viewable sample, and the validation report that points out some of the errors it contains. The feed validator misses further errors to do with nonstandard tags that have not been marked as such with the apple-wallpapers: namespace prefix. Update: The validator has been updated to catch these errors.

The long and short of it is that Apple’s new iPhoto 6 produces invalid RSS that most feed readers will be unable to process. In order to hide this fact, Apple has put up the equivalent of a “best experienced in Internet Explorer” page to turn its own ineptitude into a marketing opportunity.

If I had my doubts before, I stand corrected. Apple is the new Microsoft.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://www.sitepoint.com/ craiga

    A bit disappointing, but nowhere near as bad as the markup produced by iWeb.

    <div class="paragraph Body" style="line-height: 20px; ">This is my paragraph text</div>
    <div class="paragraph Body" style="line-height: 20px; text-decoration: none;"> </div>

    Hmmm… what happened to the good ol’ p element?

    P.S. What’s wrong with the apple-wallpapers: namespace? I’m not sure they’ve implemented it 100% correctly, but I thought the ability add custom elements via namespaces was the strength of RSS and other XML-based markup languages.

  • chrisb

    The feed validator misses further errors to do with nonstandard tags that have not been marked as such with the apple-wallpapers: namespace prefix

  • Sam Ruby

    I, too, don’t see the error the feedvalidator “missed”.

    The RSS 2.0 spec says “A RSS feed may contain elements not described on this page, only if those elements are defined in a namespace.”

    What may those elements contain? The RSS 2.0 spec doesn’t say. Nor can I find any documentation on the apple-wallpapers namespace, but suppose for a second that such documentation did exist and specified that apple-wallpapers:meta-data elements are to contain PhotoDate and Comments elements, and these elements are not in any namespace?

    What portion of the RSS 2.0 spec would such a definition violate?

    If RSS 2.0 had been in a namespace itself, I could have reported that somebody was using an element that wasn’t defined by the owner of that namespace, but who owns the “null” namespace?

    Further discussion here.

  • James Robertson

    I subscribed just fine using BottomFeeder.

    Apple isn’t turning all non-Mac tools away…

  • Pingback: Apple’s Would-be Monopoly | Center for Citizen Media: Blog

  • Jason Levine

    Kevin and Chris B, you say that there are tags being missed that haven’t been included in the apple-wallpapers namespace — what are those tags? I’ve now looked over that feed three times and can’t find what you’re talking about.

    And of course, as Sam’s already pointed out, the presence of apple-wallpapers elements in the feed doesn’t make it broken; Apple built its own namespace, just as the RSS 2.0 spec says it needed to do. (Yes, I’d love to see the definition of the namespace, just like Sam, but its absence doesn’t make the resultant RSS invalid, just suboptimally described.)

    In the end, this example feed you point to has two real problems — incorrectly-formatted dates (something easily fixed), and the presence of a guid element at the channel level (something that isn’t explicitly excluded in RSS 2.0, and is mandated under a different name in one of the more well-structured syndication standards). None of these prevent the feed from being read by my syndication aggregator, Gregarius; while they’re unquestionably present, they’re also reasonably minor.

  • Me

    Old news.

    Ever import Safari bookmarks in to Firefox 1.5? Watch what happens when you try to open a Safari “RSS feed bookmark” in Firefox. Wow – incompatible. So Firefox asks to open it in Safari.

    Sad.

  • Mike Heinz

    Ummm… The feed displays fine in NetNewsWire.
    It does fail in Firefox’s sage plug in, however.

  • Sam Judson

    I think the PhotoDate and Comments elements, within the apple-wallpaper:metadata element are whatg is being referred to. I’m not sure if sub elements also need to be qualified though?

  • Moof

    I notice that your feed doesn’t validate too, and it has far more errors (20, I mean, TWENTY errors!)

    So… does this mean that YOU are the new Microsoft? ;-)

    Please don’t take this seriously, I’m just pointing out that it’s difficult to find perfectly well-formed RSS feeds on the Internet. Photocasting works for me, it works in Safari, in NetNewsWire and in Vienna (another RSS reader). Apple can make mistakes, they will probably correct them in a later version of iPhoto.

  • Joe

    It is pretty obvious that whoever developed the feed just didn’t understand xml namespaces. First of all the apple-wallpaper namespace wasn’t declared with an xmlns attribute anywhere. The x in <x:y> is only a shortcut for the full URI of the namespace. There should be a xmlns:apple-wallpaper=”” someplace.

    Second of all, it *is* required to put the namespace prefix on subelements unless you set up a new default namespace. This can only be done (again) with an xmlns attribute. This time it should look like: xmlns=”” on the first element of the subtree in the new namespace.

    So not only is this not valid RSS, it isn’t even valid XML.

  • Tim

    The feed also displays fine in the Vienna freeware newsreader.

  • Michael

    http://www.bloglines.com shows the feed nicely.

    cute kid!

  • eduo.info

    It’s amusing. I don’t find any reply from the author. From what I can see it seems he was incredibly hasty to write this up and now that he’s been called on the errors in the piece (I don’t understand where did the notion that the RSS couldn’t be opened in other readers came from) no correction, update or reply has been made.

  • rY.

    I suggest that anyone legitimately concerned about RSS compatibility errors submit feedback at this page:

    http://www.apple.com/feedback/iphoto.html

    You might include a link to the validation page referenced in the article, if you feel its results are valid:

    http://feedvalidator.org/check?url=http://static2.podcatch.com/blogs/gems/snedit/rss.xml

  • sundoggy

    NetNewswire would work fine because it’s built on webkit, which is the base of Safari. So any Mac ap that uses webkit (well a current one) should work.

  • Charles Miller

    I was writing a tool to view photocasts in a wiki, and I found the workaround for this problem in about five minutes. Any user-agent can download the photocast simply by replacing ‘photocast.mac.com’ with ‘web.mac.com’ in the URL.

  • dizzle

    If it’s only usable with iPhoto (to view the photos), then why all the complaining? The Macs that can run this version of iPhoto will also have Safari on them for free, so relax. This isn’t an issue for Windows or non-Mac or non-iPhoto users as they can’t get the photos anyway.

  • http://www.lowter.com charmedlover

    Ah!!! Now SitePoint is anti-Opera and anti-Apple. It’s a consipiracy I swear….

    I subscribed fine using Opera (just make sure you don’t have it set to supress images, otherwise obviously you cannot see it, obviously).

    I have a strong feeling Apple will fix this. You must have forgotten that Safari was the first official browser to release an Acid2 passing browser. They also update their software quite frequently in OS X. You must not keep up Kevin!

  • http://www.lowter.com charmedlover

    (I can’t edit my comments?)

    You should also look at this:

    http://validator.w3.org/check?uri=http%3A%2F%2Fwww.sitepoint.com%2F

    Practice what you preach. They have less errors than you all do.

  • aafuss

    Babya Discoverer RSS‘s bView displays photocasts fine.

  • Jason Levine

    Joe, your point would be well taken… except for the fact that it doesn’t look like you looked at the RSS file at all. For example, you say that one problem is the lack of a definition of the XML namespace via an xmlns: declaration — except that line 2 of the document DOES have the apple-wallpapers namespace declared, with the statement:

    <rss version=”2.0″ xmlns:apple-wallpapers=”http://www.apple.com/ilife/wallpapers”>

    You also state that another problem is the lack of prefixing of any of Apple’s special XML elements in the document… except that every single one of the special tags — photoDate, cropDate, thumbnail, image, metadata — is prefixed with the apple-wallpapers: tag. Every last one of ‘em.

    Kevin, the Atom feed for this very site is much more broken than for Apple’s photocasts; in addition, you seem to have just taken Dave Winer’s claim of a broken Apple spec and republished it without ever validating anything that it contained. Like I said above, the worst thing you can say about the photocast feeds is that they incorrectly format their dates (assuredly a problem, but something that none of my RSS readers have a problem with), and that they include an element at the channel level that isn’t required, but also isn’t explicitly excluded. And looking at the validator link you yourself published would have told you every bit of this, so you should have known better.

  • FredCintra

    I use Firefox 1.5
    I’ve added a livebookmark from this link and works fine

    http://web.mac.com/mrakes/iPhoto/photocast_test/index.rss

  • Robert Jung

    So, considering all the ruckus Kevin made about this — and all the other folks who’ve subsequently proved him wrong — shall we expect an apology or retraction any time soon?

    –R.J.
    http://www.electric-escape.net/

  • http://www.sitepoint.com/ Kevin Yank

    John Levine:

    You also state that another problem is the lack of prefixing of any of Apple’s special XML elements in the document… except that every single one of the special tags—photoDate, cropDate, thumbnail, image, metadata—is prefixed with the apple-wallpapers: tag. Every last one of ‘em.

    Um, no:

    <apple-wallpapers:metadata>
      <PhotoDate>2159.525069</PhotoDate>
      <Comments></Comments>
    </apple-wallpapers:metadata>

    PhotoDate and Comments are not prefixed. They need to be.

  • http://www.sitepoint.com/ Kevin Yank

    Moof:

    I notice that your feed doesn’t validate too, and it has far more errors (20, I mean, TWENTY errors!)

    So… does this mean that YOU are the new Microsoft? ;-)

    We would be anxious to correct such errors. Can you point any of them out? At a glance, our feed certainly seems valid: feedvalidator.org report.

    Update: Found the errors in our Atom feed. We’ll fix them today. Thanks for pointing them out!

  • http://www.sitepoint.com/ Kevin Yank

    charmedlover:

    You should also look at this:

    http://validator.w3.org/check?uri=http%3A%2F%2Fwww.sitepoint.com%2F

    Practice what you preach. They have less errors than you all do.

    On the one hand, I’d say HTML validation errors are much less severe than RSS validations errors, as the former is not commonly processed as XML while the latter is.

    On the other hand, we work hard to keep as much of our site valid XHTML as possible. In this case it looks like one of our advertisers mucked up the works with some bad HTML. Thanks for pointing this out — it’s now fixed.

  • Joe

    Jason Levine:

    the document DOES have the apple-wallpapers namespace declared

    Heh — I could’ve sworn that I it didn’t have that when I looked at the feed right as this story was breaking. If it was always there then I stand corrected. There is still the issue with child elements and such that Kevin points out.

  • Jason Levine

    Kevin:

    PhotoDate and Comments are not prefixed. They need to be.

    Ummm… not by my read of the XML spec. According to the W3C:

    The namespace declaration is considered to apply to the element where it is specified and to all elements within the content of that element, unless overridden by another namespace declaration…

    The only possible argument against this is that somehow those two elements belong to the default (null) namespace, despite being underneath elements to which another namespace has been explicitly declared — but as Sam Ruby pointed out, RSS 2.0 itself doesn’t belong to any namespace, so it’s unclear what it means that any element belongs to the null namespace. (As it stands, every RSS 2.0 document has an ambiguous null namespace.)

  • http://www.sitepoint.com/ Kevin Yank

    Jason, you need to understand XML namespaces before you start claiming people have gotten them right or wrong.

    The namespace declaration is considered to apply to the element where it is specified and to all elements within the content of that element, unless overridden by another namespace declaration…

    Here’s a namespace declaration:

    xmlns:apple-wallpapers="http://www.apple.com/..."

    Indeed, it applies to the element in which it is specified (rss) and all elements inside it. It sets up the apple-wallpapers prefix to indicate Apple’s custom namespace.

    That doesn’t change the fact that elements within that namespace all need to have the namespace prefix from that declaration. The only exception would be if you declared Apple’s “wallpapers” namespace as the default namespace for the metadata element:

    
    <metadata xmlns='http://www.apple.com/ilife/wallpapers'>
      <PhotoDate>2159.525069</PhotoDate> 
      <Comments></Comments> 
    </metadata>
    

    But Apple isn’t doing this either.

    The only possible argument against this is that somehow those two elements belong to the default (null) namespace, despite being underneath elements to which another namespace has been explicitly declared

    Exactly. That’s how XML namespaces work. Just because an element is in a namespace doesn’t mean any of its descendant elements are also in that namespace by default.

    but as Sam Ruby pointed out, RSS 2.0 itself doesn’t belong to any namespace, so it’s unclear what it means that any element belongs to the null namespace.

    The default namespace (or a “null namespace”, as you put it) is not as ambiguous as you make out. Just because an XML document doesn’t have a default namespace URI assigned to it doesn’t mean that it has no rules as to what tags can and cannot be put into it.

    RSS processors identify RSS documents by virtue of the fact that they have an rss element at their root. Reinforcing this with a standard namespace URI would allow you to differentiate between actual RSS documents and other XML documents that just happen to have an rss element at their root. Apparently the writers of the RSS spec decided that wasn’t a big enough concern to warrant requiring a standard namespace URI for the RSS standard.

    But that doesn’t change the fact that elements in the default namespace of an RSS document must be valid RSS elements.

    (As it stands, every RSS 2.0 document has an ambiguous null namespace.)

    There’s nothing ambiguous about the default namespace. RSS just doesn’t mandate a standard URI for it. It does, however, specifically state that non-RSS elements must be delcared to be in a specific namespace.

  • Jason Levine

    I’m pretty comfortable taking the reading of those over in Sam Ruby’s thread, that at a minimum the idea of a non-namespaced child of a namespaced child of a non-namespaced child of a non-namespaced element is ambiguous at best. But that being said, it’s hard to say things like “RSS doesn’t mandate a standard URI for [its default namespace]“, and that “just because an XML document doesn’t have a default namespace URI assigned to it doesn’t mean that it has no rules as to what tags can and cannot be put into it” — RSS doesn’t get to change the overarching XML spec, and XML specifically *does* say that if there’s no default namespace declared, there are precious few rules about what tags can and can’t be contained within it. It’s been the complaint since day one that RSS 2.0′s author did not choose to develop a namespace for it, and thus, there are no ways for validators or parsers to actually be able to determine what belongs and does not belong in an RSS 2.0 document.

    Obviously, we don’t see eye to eye on this one; I just am not willing to say that we should reject Apple’s photocast feeds because they don’t adhere to the strict rules of XML (again, an ambiguous statement), but we should accept the base of RSS 2.0 despite the fact that it doesn’t adhere to the need for an explicitly-declared, well-defined default namespace. We either need to be consistent in our requirement for well-defined namespaces, or lax in that requirement — in the first case, RSS 2.0 fails, and in the second, there aren’t any problems at all.

  • http://www.sitepoint.com/ Kevin Yank

    Jason,

    There are the rules of XML, and there are the rules of RSS. Apple’s photocast feeds are certainly valid XML, because all XML requires is well-formedness. From the beginning, my beef has been with photocast feeds not being valid RSS.

    at a minimum the idea of a non-namespaced child of a namespaced child of a non-namespaced child of a non-namespaced element is ambiguous at best.

    Not at all. The standards are very specific about this, and it is done all the time in XSLT. Consider this common XSLT template that outputs HTML:

    <xsl:template match='/'>
      <html>
        <head><title>Sample Page</title></head>
        <body>
          <xsl:apply-templates />
        </body>
      </html>
    </xsl:template>

    Those HTML tags in the template are still HTML, even though they are descendants of an element in the XSLT namespace. The default namespace in this document is HTML.

    The only difference between the above example and RSS is that RSS has no standard namespace URI that should be used to identify its tags.

    RSS doesn’t get to change the overarching XML spec, and XML specifically *does* say that if there’s no default namespace declared, there are precious few rules about what tags can and can’t be contained within it.

    As I mentioned above, the only thing XML requires is well-formedness. Beyond that, the only thing that can specify what can and can’t go into an XML document is a spec like RSS 2.0 (which can be made machine-enforcable through a DTD).

    The purpose of namespaces, rather, is to identify elements that belong to a given XML language when they are embedded in an XML document of a different type. Since there is no convincing use case for RSS 2.0 elements to be embedded in another XML document, there was no pressing need to specify a standard namespace URI for it.

    It’s been the complaint since day one that RSS 2.0’s author did not choose to develop a namespace for it, and thus, there are no ways for validators or parsers to actually be able to determine what belongs and does not belong in an RSS 2.0 document.

    Namespaces do not identify what DTD to use to validate a document. That’s what document type declarations (<!DOCTYPE ...>) are for. A more valid complaint would be that RSS 2.0′s author didn’t develop a formal DTD (or XML Schema) that could be used to validate RSS 2.0 documents. That’s why tools like the Feed Validator are necessary.

    I just am not willing to say that we should reject Apple’s photocast feeds because they don’t adhere to the strict rules of XML (again, an ambiguous statement),

    I’m not saying anything of the kind. It’s the strict rules of RSS 2.0 that they don’t adhere to.

    but we should accept the base of RSS 2.0 despite the fact that it doesn’t adhere to the need for an explicitly-declared, well-defined default namespace.

    There is no such need. Not even the XML Namespaces spec itself requires all elements to have an assigned namespace URI. XML documents were being validated long before XML namespaces came along.

  • Pingback: And He Blogs » Blog Archive » Photocasting - Not Quite Standard RSS

  • Mark Pilgrim

    Despite the naysayers here who can’t see anything wrong with iPhoto’s RSS implementation, it really is spectacularly bad:

    http://lists.apple.com/archives/syndication-dev/2006/Jan/msg00020.html

  • Hugues Lamy

    Without too much proof, it takes Apple three releases to get the best of their new technologies. It was pretty much the case for their OS and ITune.

    I don’t know if Apple if following Agile development strategy, but putting something on the market, getting feedback and producing upgrade few months later sound like Agile. Get your product on the market have it discuss good or bad and learn from it. Stop the project and save money if this is not good, or improve on the knowledge.

    Now for the RSS feed, I’ll leave that to other to discuss if it is incorrect or some readers doesn’t support the standard.

    Have a good day.

    Hugues Lamy

  • http://www.sitepoint.com/ Kevin Yank

    Thanks for that link, Mark. Though my main concern with iPhoto is the feed generated by their service, the state of their preferred client goes a long way towards explaining it:

    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.

  • http://www.lowter.com charmedlover

    On the one hand, I’d say HTML validation errors are much less severe than RSS validations errors, as the former is not commonly processed as XML while the latter is.

    My only point here is that you aren’t pefect either. I think the few errors in Apple’s generated feed are not drastic enough to lash out at them to this point. While I agree it should be brought to Apple’s attention you are taking it a level too far, elevating it to an unacceptable level.

    I find you are simply looking for a small flaw in Apple’s system to criticize them just for the sake of criticizing them.

    As mentioned earlier, Apple is good about fixing flaws such as this and getting them cleaned up. That is why Safari had the first official release of a browser that passed Acid2.

    For such a small error you’re making an alwful big deal about it. I haven’t seen any lashing for the HTML generated by FrontPage?

  • http://www.sitepoint.com/ Kevin Yank

    charmedlover:

    For such a small error you’re making an alwful big deal about it. I haven’t seen any lashing for the HTML generated by FrontPage?

    That’s because there’s still hope for Apple. :)

  • Me

    Of course, maybe this is an intelligently written post which is designed just to get attention. And draw attention to the advertising.

    Bashing Apple Sells newspapers

  • anonymous

    “the new Microsoft” – Kevin, what ever you are smoking, either cut back on it or blog about it so the rest of us can join in.

  • Pingback: brainpipe » Apple defines Really Sucky Syndication standard

  • Larry

    Even with a compatible feed reader, the actual feed is not located at photocast.mac.com/… but at the URL that’s specified in the error message. Apple is looking at the User-Agent, and if it’s supported (eg, it contains “NetNewsWire/”) it returns a 302 redirect to the actual feed.

  • Pingback: » links for 2006-01-20  InsideMicrosoft - part of the Blog News Channel

  • http://www.sitepoint.com AlexW

    Zeldman’s take on the issue — iPhoto , iTunes, iForgotToTest

    I think it more likely that Apple’s implementation is simply, grandly inept.

    It may be inept through knuckle-dragging unawareness of best practices in web design, as is the case with iWeb’s HTML markup.

    Or it may be inept because it was rushed to market.

  • clintonG

    Apple has also published invalid examples of RSS 2.0 in the iTunes specification [1]. See “An Example Feed” and note there is no element in the channel. I’m discussing this and other “missing information” in their syndication-dev@lists.apple.com list.

    I encourage others to show up in that list and support the concerns I have discussed as well as any you may have yourself.

    [1] http://www.apple.com/itunes/podcasts/techspecs.html

  • Carlos

    More a question than a statement.

    One of the iPhoto photocasting feeds I subscribe to is

    http://www.maharaj.org/rdf.xml

    It appears (to me, anyway) to be:

    (1) iPhoto compatible and iPhoto RSS sound
    (2) Yahoo media RSS compatible
    (3) RSS 2.0 valid
    (4) .mac independent

    Am I right about that? If so, should/could I use it as a template for my own photocast, or is there something here that I’m completely missing?

    Tx