(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 Update: The validator has been updated to catch these errors.apple-wallpapers: namespace prefix.
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.
Learn about this Book
FREE Sample
January 17th, 2006 at 3:25 am
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’
pelement?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.January 17th, 2006 at 7:26 am
The feed validator misses further errors to do with nonstandard tags that have not been marked as such with the apple-wallpapers: namespace prefix
January 17th, 2006 at 7:32 am
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.
January 17th, 2006 at 9:21 am
I subscribed just fine using BottomFeeder.
Apple isn’t turning all non-Mac tools away…
January 17th, 2006 at 9:44 am
[…] Kevin Yank calls Apple the “new Microsoft” — and in the case of online music there’s certainly some truth in that notion. I have to believe that in this case the problem is less mean-spirited. Apple probably rushed this product feature out the door, testing only on its own browsers. We’ll know soon, because if this exclusionary tactic persists, it will tell us mainly that Apple is more foolish than we might have guessed. Filed under News by Dan Gillmor. Permalink • Print • Email […]
January 17th, 2006 at 9:56 am
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.
January 17th, 2006 at 12:02 pm
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.
January 17th, 2006 at 12:14 pm
Ummm… The feed displays fine in NetNewsWire.
It does fail in Firefox’s sage plug in, however.
January 17th, 2006 at 12:18 pm
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?
January 17th, 2006 at 1:28 pm
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.
January 17th, 2006 at 1:48 pm
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.
January 17th, 2006 at 2:01 pm
The feed also displays fine in the Vienna freeware newsreader.
January 17th, 2006 at 2:06 pm
http://www.bloglines.com shows the feed nicely.
cute kid!
January 17th, 2006 at 2:09 pm
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.
January 17th, 2006 at 2:45 pm
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
January 17th, 2006 at 3:43 pm
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.
January 17th, 2006 at 4:42 pm
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.
January 17th, 2006 at 4:58 pm
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.
January 17th, 2006 at 5:15 pm
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!
January 17th, 2006 at 5:17 pm
(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.
January 17th, 2006 at 6:12 pm
Babya Discoverer RSS’s bView displays photocasts fine.
January 17th, 2006 at 7:30 pm
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.
January 17th, 2006 at 7:39 pm
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
January 17th, 2006 at 7:59 pm
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/
January 17th, 2006 at 8:54 pm
John Levine:
Um, no:
PhotoDateandCommentsare not prefixed. They need to be.January 17th, 2006 at 8:59 pm
Moof:
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!
January 17th, 2006 at 10:02 pm
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.
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.
January 17th, 2006 at 10:10 pm
Jason Levine:
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.
January 17th, 2006 at 10:12 pm
Kevin:
Ummm… not by my read of the XML spec. According to the W3C:
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.)
January 17th, 2006 at 10:27 pm
Jason, you need to understand XML namespaces before you start claiming people have gotten them right or wrong.
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 theapple-wallpapersprefix 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
metadataelement:But Apple isn’t doing this either.
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.
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
rsselement 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 anrsselement 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.
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.
January 17th, 2006 at 10:45 pm
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.
January 17th, 2006 at 11:14 pm
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.
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:
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.
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.
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’m not saying anything of the kind. It’s the strict rules of RSS 2.0 that they don’t adhere to.
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.
January 18th, 2006 at 11:27 am
[…] […]
January 18th, 2006 at 1:12 pm
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
January 18th, 2006 at 3:09 pm
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
January 18th, 2006 at 7:47 pm
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:
January 18th, 2006 at 11:17 pm
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?
January 18th, 2006 at 11:22 pm
charmedlover:
That’s because there’s still hope for Apple. :)
January 19th, 2006 at 1:48 am
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
January 19th, 2006 at 5:40 am
“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.
January 19th, 2006 at 9:23 pm
[…] Steve Jobs is a salesman. He’s possibly the best salesman on the planet, but that doesn’t make him a god, or even someone worth your attention. It means his purpose in life is to clean your wallet. And guess what? He’s done a respectable job thus far. Not exactly in Bill Gates territory (although Kevin Yank says Apple is the new Microsoft, but it beats the hell out of working for a living. It’s a lot like half the U.S. population bitching about the sinking ship they’re on: Bitch away, Mary, but you created this mess. […]
January 19th, 2006 at 9:30 pm
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.
January 19th, 2006 at 11:12 pm
[…] SitePoint Blogs » Apple “photocasting” Mac only, uses invalid RSS Quote: “If I had my doubts before, I stand corrected. Apple is the new Microsoft.” Wow. (tags: apple mac iphoto rss) […]
January 23rd, 2006 at 7:38 pm
Zeldman’s take on the issue — iPhoto , iTunes, iForgotToTest
February 10th, 2006 at 6:59 pm
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
April 6th, 2007 at 4:39 am
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