It’s just data

Photocasting

Dave Winer: Here’s a look at the “photocasting” feed format that Apple introduced yesterday. It’s fairly bad.

It’s not quite valid.

Either they are improving it in realtime, or they are down to three basic errors: incorrect mime type, they provide a feed level id (something Atom requires and RSS 2.0 doesn’t directly have support for), and use nearly RFC 3339 formatted dates (again nearly Atom).

If they are going to go this far, why not go with Atom?  ;-)

Oh, and some documentation for the wallpapers namespace would be nice.


Actually, there’s a fourth class of error, but we miss it and I’m afraid I’m not smart enough to fix us: they have a couple of non-namespaced elements inside the namespaced apple-wallpapers:metadata element, so we should be saying “There is no RSS element ‘PhotoDate'” and “There is no RSS element 'Comments’.”

Posted by Phil Ringnalda at

Dave Winer Specifications

It seems to me that a Dave Winer specification is often seen an invitation to free-for-all improvisation rather than a definition of how a protocol should be implemented. Dave and Sam Ruby have posted about the photocasting feed format that...... [more]

Trackback from Cook Computing

at

Phil: that would presume that RSS 2.0 “owns” all non-namespaced elements... something that seems a bit presumptuous, wouldn’t you say?

Posted by Sam Ruby at

"Photocasting"

James Holderness (check the comments) Do you ever think maybe the Apple guys are just winding you up? Nobody could possibly be that stupid. Maybe, though I tend to share Phil’s skepticism. Lets start the with the name, “photocasting”. Worst name...

Excerpt from Laughing Meme at

I don’t know of any other way of interpreting a format that’s namespace aware but not namespaced itself. Is there one? Do I not understand how namespacing and inheritance works? Would a-w:metadata/comments be an RSS comments element, or not?

Posted by Phil Ringnalda at

Would a-w:metadata/comments be an RSS comments element, or not?

Perhaps.  But then again, perhaps not.

If I said “I am thinking of a president named George”, could I be thinking of George Washington?  Unless I tell you the last name, you can’t be sure, can you?

All I know is that the RSS 2.0 Specification states which elements may be children of <rss>.  For the elements it lists, it goes on to and describe whether or not child elements are OK.  For elements in a namespace, it is silent as to which elements it may contain.

If we ever see a specification of what elements an <apple-wallpapers:metadata> element expects as children, then we will have a better understanding as to what child elements we can expect.

Just to be clear: I like to have the feed validator spit out error messages.  I really do.  But at the moment, I am not prepared to go so far as to say “here is an element in an unknown namespace, and it has a child which I don’t recognize, therefore it is illegal”.

Posted by Sam Ruby at

I think the point is not so much “it has a child which I don’t recognize” as it is “it has a child which is in the default namespace.” Which I think is fair game to make a warning out of, if not an error; remember what happened when Microsoft’s Simple List Extensions stuck a <title> into a namespaced element.

Posted by Aristotle Pagaltzis at

Aristotle,

First a quibble, this has nothing to do with default namespaces.  It is quite possible to create an Atom document in which the default namespace is xhtml, and every element which is not in that namespace is explicitly qualified.

We are talking about elements which are not considered to be in any namespace.

Let me return to my “presumptuous” comment above.  Joe Gregorio defined a wfw namespace.  Given that he owns the URL, I’m willing to consider Joe authoritative on what goes in that namespace.

Who own the definition of all elements which are not in any namespace?  I’m not willing to cede that to anyone.

Posted by Sam Ruby at

Err, yes, sorry, I meant the null namespace.

While you’re right, the code most people write probably has certain expectations about the meaning of the null namespace in the context of an RSS feed. Then again, said code will probably also ignore unfamiliar elements. I guess that means there should be a warning about namespaceless elements iff they’re also used in RSS (such as <title>), since there is potential for confused software.

Posted by Aristotle Pagaltzis at

Eh, I give up, you’re right. Microsoft wants non-namespaced children of namespaced elements to mean what they want them to mean, Apple wants them to mean what they want, and oddly enough there doesn’t seem to be any spec text written covering the meaning of a non-namespaced child of a namespaced child of a non-namespaced child of a non-namespaced non-DTD document element. So, they mean exactly what Humpty-Dumpty wants them to mean, and I just need to get over feeling like I just played a game of Simon Says where only three of the four rules were explained to me before the final double-or-nothing round.

Posted by Phil Ringnalda at

Phil, if it helps, I would prefer not to preclude the inclusion of non-namespaced elements inside of atom:content.  vCard or xCal for example.

And how about this for a trip down memory lane?

As I see it, understanding nesting and understanding namespaces is simply a pre-req for anybody who purports to implement RSS 2.0.

Posted by Sam Ruby at

The good news (for me) is that FeedTools took one look at the feed, shrugged, and parsed it the way Apple probably meant for it to be parsed.  Though I have to admit to being annoyed at yet another ugly and seemingly redundant spec from Apple.

Is it just me or couldn’t pretty much everything in this “spec” be replaced with the yahoo media extensions?

apple-wallpapers:image  = media:content
apple-wallpapers:thumbnail = media:thumbnail
apple-wallpapers:photoDate = unnecessary due to EXIF?
apple-wallpapers:cropDate  = just plain unnecessary?
apple-wallpapers:metadata  = hard to tell, looks like just a comment and another date...  comment could be stored in media:description quite legitimately.

Oh well.  FeedTools will probably just stuff the apple-wallpapers stuff into an enclosure object.

Posted by Bob Aman at

Not to derail the lovely conversation here, but I’m much more worried about Apple’s implementation of one-click subscribe.  iPhoto 6 gives you a URL like this:

[link]

As Dave and others have pointed out, this isn’t really the feed URL (despite the “index.rss” faux-filename).  It’s an HTML page full of nasty JavaScript (deconstructed here) that checks whether iPhoto is the registered handler for the “application/photo” MIME type.  As far as I can tell, application/photo is not an IANA-registered MIME type (cache); Apple appears to have just made it up.  (I am willing to be proven wrong.  Maybe they just haven’t updated their web site.  Show me the registration.)

If this JavaScript sniffer code determines that you are worthy of receiving the actual feed, it redirects to the real feed URL ("web.mac.com" instead of "photocast.mac.com"), and Safari passes it off to iPhoto, which presumably subscribes.  If not, you get an HTML page with a pretty error message telling you you’re using incompatible software.

This, in a word, sucks.  If other publishers start doing this (each in their own way, of course), we’re all screwed.

In the short term, I’ve written a Greasemonkey script that turns the pretty error message into something more useful: Friendly Photocasting user script, screenshot.  This will at least insulate you from Apple’s incompetence if people send you iPhoto-generated faux-feed URLs.  It does nothing to solve the more fundamental problems with Apple’s approach.

Posted by Mark at

Excellent Mark. Your a greasemonkey genuis. You should write a book or something.

Oh, and I just noticed firefox 1.5 prompts you to install greasemonkey scripts when you click on them. Also excellent.

Posted by Darryl at

Apple obviously doesn’t give a shit. They’ve gotten enough bad feedback on their other syndication format efforts to know that they might have a problem.

I bet this format will enjoy more support than Media RSS, at least in the near term. I think the relevant rule from the RSS Extension Predictor Success Matrix is “Extension useful for something other than producing web pages”. Showing the input to the Apple apps can only encourage clones, but you can bet they won’t be as well executed.

Posted by Robert Sayre at

New RSS Module

Via Sam Ruby, I see that Apple has added yet another RSS Module into the mix - Dave Winer has a critique on it here. I added support for it in BottomFeeder this morning; grab the update and the example feeds should give you the extra information. I...

Excerpt from Smalltalk Tidbits, Industry Rants at

So, would be it too difficult for the feed validator to spit out an UndocumentedPieceOfCrap error when it finds one of those weird PhotoDate elements?

Posted by Mark at

Regarding Phil’s comments, in any XML dialect, when should a namespaced element have children that belong to a default namespace? My first pass at this issue is that you’d want to do one of two things with those children:

1. Assume they are part of the parent’s namespace.

2. Flag them as errors.

The assumption that they belong to the default namespace is a big leap. In an RSS 2.0 feed, why would the pubdate element of cadenhead:item be treated like the pubdate element of item?

Posted by Rogers Cadenhead at

when should a namespaced element have children that belong to a default namespace?

Default namespaces are irrelevant to this discussion.  I could declare an atom prefix in my Atom feed, make the xhtml namespace the default, and all conformant RFC 4287 processors will treat the feed identically to the one that it replaced.

Assume they are part of the parent’s namespace.

That would be incorrect.  In particular, look at the last example in that section.

Flag them as errors.

Can you cite the relevant portion of the RSS 2.0 specification which would support such an interpretation?  I see an enumeration of the possible child elements of item, as well as a provision that additional child elements are allowed if they are in a namespace, but no restrictions on the subsequent structure of such elements.

why would the pubdate element of cadenhead:item be treated like the pubdate element of item?

First, pubdate is a common error in RSS 2.0 feeds.  The correct element name is pubDate.

Now to your real point: the answer is that they don’t, and that’s exactly why there is no error.  In RSS 2.0, a channel pubDate has a different meaning than an item pubDate.  They happen to have the same format, but they need not have.  Furthermore, I don’t see how anything in RSS 2.0 specification limits in any way what elements you may define to be as valid children of cadenhead:item elements.

Posted by Sam Ruby at

First, pubdate is a common error in RSS 2.0 feeds.  The correct element name is pubDate.

Ouch.

I was using “default namespace” to mean “elements with no namespace at all.” Sorry.

In the Beers example, the table element declares the HTML namespace as the default. I’m presuming that this means that the enclosed th and tr elements inherit this declaration, putting them in the same HTML namespace also.

So if an element can inherit a parent’s default namespace declaration, why wouldn’t it follow that an element inherits a parent’s namespace?

I’m confused by the notion that a namespace could include no-namespace or default-namespace elements. How is this preferable to inheriting a namespace in the absence of some form of declaration to the contrary?

Posted by Rogers Cadenhead at

I’m confused by the notion that a namespace could include no-namespace or default-namespace elements. How is this preferable to inheriting a namespace in the absence of some form of declaration to the contrary?

It is not a matter of what is preferable, it is a matter of what the spec says.

And the spec is pretty straightforward, and the spec isn’t very long.  Still, let me net it out for you:

One only inherits default namespaces.

Now, let’s illustrate that with a simple example:

<outer xmlns="http://outer" xmlns:mid="http://mid">
  <mid:element>
    <inner/>
  </mid:element>
</outer>

In this example, inner inherits not from the namespace of the parent, but from the default namespace of the parent, which it in turn inherits from its parent.

So, the effective namespace for the inner element is http://outer.  Not the namespace of the parent element, namely http://mid.  And this is not a matter of preference, it is a matter of what the spec says.

Now, for a more complete example, if you take a look at the beers example, th and tr are in the html namespace and pro and con are in no namespace at all.

As are the PhotoDate and Comments elements in the Apple photocasting feed.

Posted by Sam Ruby at

One only inherits default namespaces.

I can’t find language in the spec that makes this explicit, but I’ll keep looking. Getting back to the key question in regard to RSS 2.0:

Can you cite the relevant portion of the RSS 2.0 specification which would support such an interpretation?

The spec defines the required and optional elements of an RSS feed. Every one of these elements has an explicit parent-child relationship that can be checked by a validator.

If RSS 2.0 can’t state that PhotoDate is invalid because it does not “own” elements outside of namespaces, as you suggest, it can’t declare any non-namespaced element invalid.

That seems like an odd interpretation of what to do with formats like RSS 2.0 that are older than XML namespaces.

I note that my test RSS feed with a PhotoDate child of item is rejected as “Undefined item element: PhotoDate” by the Feed Validator.

Posted by Rogers Cadenhead at

The spec defines the required and optional elements of an RSS feed. Every one of these elements has an explicit parent-child relationship that can be checked by a validator.

Yes

If RSS 2.0 can’t state that PhotoDate is invalid because it does not “own” elements outside of namespaces, as you suggest, it can’t declare any non-namespaced element invalid.

No.

That seems like an odd interpretation of what to do with formats like RSS 2.0 that are older than XML namespaces.

It would be an odd interpretation, if, in fact, anybody were proposing it.  (Note to self: re-read and internalize Scott Adams' Results of Why I’m Stupid)

Oh, and by the way,

I note that my test RSS feed with a PhotoDate child of item is rejected as “Undefined item element: PhotoDate” by the Feed Validator.

The RSS specification defines what the valid children of item are.  PhotoDate is not in the list.  By rule, apple-wallpapers:metadata is.  Hence the “Undefined item element: PhotoDate”.  The issue isn’t that PhotoDate isn’t valid.  The issue is that it isn’t defined as a valid child of item.

Some, apparently unpublished, Apple specification defines what the valid children of apple-wallpapers:metadata are.  Until I see that specification, I can’t say that whether Apple is using PhotoDate correctly or incorrectly.

Posted by Sam Ruby at

Default namespaces are irrelevant to this discussion.  I could declare an atom prefix in my Atom feed, make the xhtml namespace the default, and all conformant RFC 4287 processors will treat the feed identically to the one that it replaced.

If only reality were that simple. It turns out that “conformant” is the key word, and I discovered the hard way that most of them aren’t.

Posted by Aristotle Pagaltzis at

RSS 2.0 is dated September of 2002.

I’m referring to the RSS 0.90/0.91/0.92/2.0 format as “RSS 2.0” to avoid confusion with RSS 1.0. RSS 2.0 predates namespaces.

I think the simplest interpretation of the PhotoDate problem is that elements in no namespace are invalid if not explicitly covered by the RSS 2.0 spec.

The spec states that “[an] RSS feed may contain elements not described on this page, only if those elements are defined in a namespace.”

PhotoDate is not defined in a namespace and is not described in the spec, so it’s invalid. The fact that its parent is in a namespace should be irrelevant, because as you have said, “One only inherits default namespaces.”

Posted by Rogers Cadenhead at

I’m referring to the RSS 0.90/0.91/0.92/2.0 format as “RSS 2.0” to avoid confusion with RSS 1.0. RSS 2.0 predates namespaces.

RSS 0.90 is commonly seen as the predecessor to RSS 1.0 not RSS 2.0, but even that format was released three months after XML namespaces was made a final recommendation  And RSS 0.90 included namespaces, a feat that would have proven difficult if it had predated namespaces.

But, as we learned previously, the definition of RSS 2.0 is subject to many interpretations, and I’m tired of arguing.  So like I did with the how many enclosures does RSS 2.0 allow per item discussion (another discussion that never lead to a clear conclusion), I’m simply going to shut up and implement the check.  But only for RSS 2.0 based feeds.  And with a solution that states that the person creating the feed is out of luck, either she needs to find another extension or she needs to switch feed formats.

Expect this to go online by tomorrow morning.

And like I said with the enclosures case, I’ll switch it back if unnamespaced child elements of valid extentions is later determined to be acceptable.

Let me know if I can be of further help.

Posted by Sam Ruby at

Of course the simple answer is add an xmlns=… attribute to the aw:metadata tag so that the unnamespaced elements inherit the new default namespace (i.e. apple’s). iPhoto will likely not even notice :)

Posted by Nicholas Shanks at

Thereby creating a private variant of an undocumented vocabulary. Now why doesn’t that sound like such a hot idea to me…

Posted by Aristotle Pagaltzis at

Add your comment