Meet the new boss

What’s the acronym for “rolling on the floor, choking and gasping while pissing myself”? Oh, yeah.


Welcome a new shooter (yup, intended) to the Syndication Wars! Daniel Henry’s SDF would like to be the one true format that sneaks through the underspecified, overspecified, overacrimonious mess we currently have, to be so clear and pure and safe and flexible that Aunt Tillie will hand-code her recipies in it while her nephew Mr. Safe convinces his company to publish every word they emit in it as well.

Eh, it only took me about ten minutes to support it (assuming my current minimal version is right): index.sdf.

Oh, you won’t actually be able to conveniently follow that link, will you? Between the type application/sdf+xml and the fact that SDF mandates that all links to its files be in the sdf: pseudo-protocol, you’ll need to install an SDF reader, and have it register as an SDF handler.

But the “my way or the highway” fun doesn’t stop there: at the top of the spec is a warm-fuzzy Creative Commons (by-nd) license, but at the bottom is:

Closed extension

Closed extension means that absolutely no one but the collective authors of this specification are granted the right to create future versions of the SDF document type. SDF has been copyrighted, trademarked and/or patented in a very strong effort on the part of Howell Developments to protect SDF from possible version skew. Anyone and everyone has been granted irrevocable permissions to produce products that use this specification to generate, catalogue, digest or use SDF documents for any purpose they wish.

However, these legal protections have been put in place to ensure that the definition of SDF documents is held centrally, as one source upon which all parties may rely, as should be the case with any true standard. Howell Developments reserves the right to pursue legal action against any entity that threatens to destabilize SDF by producing alternate versions of this document type.

Um. The specification is controlled by a working group appointed by a single vendor, who will hunt down anyone who dares use the letters SDF for anything vaguely related to syndication like a rabid dog.

Christ. This stuff writes itself.

(Via the fun folks at TheRSSWeblog)


Comment by Chris L #
2004-04-30 07:16:24

My first thought was sarcasm when I saw the first posts trickling through about Yet Another Format. But to be fair, in the discussion forums on the site for SDF Daniel Henry does say that the verbiage about the closed format is there to avoid forks that have caused all the troubles we are now facing with RSS and (it seems) he wouldn’t have a problem with development being done by a standards body or working group.

In reality, though, the only ”solution” to this problem will be technological evolution. There are too many personalities who have too much ego invested (on both sides) to allow for much else.

Comment by Mike B #
2004-04-30 08:26:11

The world of syndication is a huge battle ground where many formats fight to come out on top. SDF is no exception to this rule, however it does appear to traverse beyond just ”syndication” and instead provide a better vehicle for ”content delivery”. For that reason alone, I feel it’s far better than many of the syndication formats that are out there right now that people (incorrectly) use for content delivery.

I think you misread the specification when it came to the part about how to link to an SDF document (using the ”sdf:” protocol extension). If you re-read the specification again here, you’ll notice that it specifically says ”This section defines best practices for including links to SDF documents on web pages.” … meaning that it’s not actually REQUIRED that you use ”sdf:” in your URL. I’m personally torn between adding a new protocol extension, or merely just allowing the client to do its own thing based on the file extension/mime-type of the file. But that’s a whole-nother discussion that I don’t want to get into here.

The ”Closed Extension” seems to be one of your biggest problems with this. Try to take this a little less seriously than it appears… legal print always looks like that.

Chris L pointed it out correctly that the problem with any new standard once adoption of it becomes popular is the possibility of version forking among individuals or groups of people who think they can take the existing specification and make it better, the best example of this being the entire RSS/RDF hell. Considering that HowDev is incredibly dedicated to all forms of syndication, I’m sure that they would be open to suggestions or collaborations with others in regards to specification advancement.

Comment by Mark #
2004-04-30 10:57:55

Wow, a mysterious new syndication format, complete with patents, vendor lock-in, and a complete lack of extensibility… coupled with mysterious supporters coming out of the woodwork on day 1. *DAY 1*. Do you get paid for this, or are you doing it for free?

> the problem with any new standard once adoption of it becomes popular is the possibility of version forking among individuals or groups of people who think they can take the existing specification and make it better, the best example of this being the entire RSS/RDF hell…

Yes, well, if Dave hadn’t stolen the specification from Netscape, we’d all be a lot better off today. We are all doomed to live with the consequences of others’ mistakes. Isn’t that enough? Must we strive to make our own as well?

Comment by Phil Ringnalda #
2004-04-30 11:17:57

I might have put it a little more temperately ;), but, yes: if you want to go around supporting SDF in weblog comments, that’s great, good for you, but if you don’t add on a last name and a link to something which provides more information about who you are and what your stake is, Mark’s will probably wind up being one of the more moderate reactions.

Comment by Chris L #
2004-04-30 22:13:29

The salient point here is that the technical quality of the proposed alternative really doesn’t matter much given the environment into which it is being introduced. I don’t think the ”closed” extensions are particularly relevant either.

By far the most likely future for SDF is that it there will be a brief but intense flurry of commentary about it that is really a guise for discussing the RSS/Atom controversy and then it fades away. Or it becomes Yet Another Format causing more fractures frustrating for developers and users alike.

Comment by Phil Ringnalda #
2004-04-30 22:53:55

Agreed. Strip away the API, and the over-architecting, and what we wanted from Atom really isn’t any big deal: a clear spec, content types, separate summary and content, maybe some dates. No big deal. The only real challenge is figuring out how to get support: Sam’s approach with Atom has been to be as open as possible, let people talk and poke until everyone gets tired of talking and poking, and go to the IETF where it will get more talking and poking. Daniel’s approach, at least so far, looks very different, and also very familiar from what I’ve read of the 0.9x days. Who knows, maybe we’re ready to go back to a single strong dictator. Sometimes it works: lots of people say that’s why Firefox is so much nicer than Seamonkey, because there were only a few very strong-willed people who could put things in or take them out of Firefox.

(Though I don’t think that SDF is completely free of tech-interest: I’ll have to look more, and maybe write some parsing code, but my first impression is that the ”make it nice for producers by making everything optional” is going to wind up also being ”make it miserable for aggregator authors by making everything optional” – whether you’re looking at sorting or display, not knowing which date or dates (if any) you’ll have isn’t much fun.)

Comment by Daniel Henry #
2004-05-01 06:32:14

Yeah, I understand that making things optional makes it more difficult to parse documents. The real influence behind making so many elements optional in SDF is that we keep hearing about aggregators tearing down web servers, downloading feeds constantly. It seems as though once this technology really does start to enter the mainstream, this is going to be a serious problem for web hosts, IT guys, etc.

Given the nature of the medium, it’s difficult to get around the fact that we need to actively check documents (e.g. people are behind firewalls and NAT routers, etc.). So isn’t the next viable step to make these documents smaller, if we can? If you do not feel like including a date, then you don’t have to, and the SDF spec tells producers how to handle this. This is also a supporting reason why SDF does not allow escaped HTML/XHTML markup, unless your trying to display markup in and of itself. It simply states that everything has to be well-formed such that it can be placed in the XML and the consumers have been directed to extract it in a reverse procedure.

And again, I’m not trying to be combative, I’m just trying to explain myself ;)   If anyone has any other ideas about this whole issue, I am totally all ears!

Comment by Mark #
2004-05-01 10:53:43

Wow, talk about the wrong way to optimize for bandwidth and scalability. Create an XML format (*XML*), but then make everything optional, but then make useful things like escaped markup illegal… in the name of scalability? I can’t even argue with that, it’s so whacked, and that’s saying something, because I can argue with almost anything.

Comment by Phil Ringnalda #
2004-04-30 11:13:58

Well, ”best practices” isn’t the normative text I missed, it’s ”SHOULD” – midnight reading when you are aiming for a ten minute deployment isn’t always precise. It is, however, illustrative of how people will misinterpret you, and thus useful.

”Closed Extension” isn’t necessarily my biggest problem – I’ve only had a twenty minute glance so far. However, even though I wasn’t around at the time, I am aware of the history around the start of RSS 1.0, so I know a bit about how something which even just looks like ”one vendor, total control” will be received by people who’ve been around this block a time or two. Whether or not it’s possible to just ignore them, and push through a new spec by appealing to people with no history, just revulsion for the existing situation, is certainly an interesting question. Me, I probably would do everything I could to either make it look like every vendor was involved or that no vendor was involved. And it’s worth noting that I’ve always at least tried to stay in the middle of the road in the Syndication Wars, and I still had a ”meet the new boss” reaction to a spec filled with Howell Developments this, Howell Developments that, Howell Developments the other thing.

Comment by Mark #
2004-04-30 11:23:05

And ads. Don’t forget the Google Ads at the bottom. Because, really, nothing screams ”true standard” like putting Google ads at the bottom of your spec.

Comment by Larry #
2004-04-30 11:38:04

That’s probably to promote a ”buy-in”.

Comment by Phil Ringnalda #
2004-04-30 11:43:22

Repeating ”pissing myself” probably wouldn’t be good for search referrals for this entry, would it? I better not.

Comment by Daniel Henry #
2004-05-01 02:01:02

Hey, I’m sorry. The Google Ad thing is included in the footer dynamically and I didn’t even consider the conflict of interest in having advertisements there (I didn’t even notice them). You’re right; it is inappropriate, and thank-you for noticing. I made a flag I could set to cancel inclusion of them and used it with the spec. Please let me know about any other issues you find, and I encourage you to do it on our forum for SDF so that everyone can see!

Comment by Mark #
2004-04-30 11:36:31

Hey, if Sam implements SDF, then it’ll have twice the uptake of Hot RSS, and then I’ll *have* to support it in the Universal Feed Parser. They don’t call it ”Universal” for nothing. Actually, they call it ”Universal” mostly because calling it ”ultra-liberal” was getting me in too much trouble with dumbass XML ”experts” who seem to think that one man’s pet peeve writ large seven years ago constitutes some sort of religious doctrine, but never mind that. I’m sure that’s just my fever talking.

Comment by Phil Ringnalda #
2004-04-30 14:32:17

Actually, that argument gets much more interesting once you really look at the spec: it’s quite clear that ”a conforming XML parser” has to halt and catch fire on a fatal error, and it says not one word about what the application which invoked that parser has to do. They were very careful to draw the distinction between ”a conforming XML parser” and the application which uses it, and just as careful not to say ”an application which has once invoked a conforming XML parser to parse a document MUST NOT do anything whatsoever with that document, having once been informed by the parser of a fatal error.”

Once the argument goes from ”this is what the spec says (you bastard)” vs. ”that’s insane (you moron)” to ”this is what the spec says (you bastard)” vs. ”no, you can’t read a spec to save your life (you moron)” it gets to be a lot more fun. For some value of fun.

Comment by Mark #
2004-04-30 16:00:44

Hmm, applications defining their own error recovery by working around the draconian error handling of the underlying parser. That sounds so familiar. Can’t. Quite. Place it…

Ah yes, here it is, predicted 7 years ago:

Are you really still prohibiting the *parser* from attempting to make
what sense it can from the ”remaining text”? Sounds like that means
each application that wanted to do what it could would have to have
a built-in error-correcting parser, and the ”real” parser and the
application would have to pass the material up to the first error
(which has been already parsed and is not part of the ”remaining text”
as defined).

Comment by Phil Ringnalda #
2004-04-30 16:27:40

Ah, I do always enjoy a trip back to the parent message in that thread, where it’s Microsoft and Netscape that desperately want draconian error handling (erm, where’s that version of IE that accepts application/xhtml+xml and catches fire when it’s not wellformed?), and because a Java applet would be too big with error handling code (C&GWPM) and a banking program shouldn’t continue after an error, an RSS aggregator mustn’t massage the input before sending it through again.

Set the bozo bit in your library, don’t use a library that doesn’t set the bozo bit, and if anyone starts pushing mission critical data through RSS, make it obvious in your display when the bozo bit is set.

Seven years later, and we’re just now learning how to reliably copy text from a word processor and paste it into a browser without getting an illegal character. Zooooooooom!

Comment by Daniel Henry #
2004-05-01 01:02:41

After speaking my uncle, who is an attorney, I think you guys are right.

Comment by Jay Small #
2004-05-02 08:05:21

By the way, ”SDF” is the official abbreviation for Standiford Louisville International Airport. :-)

Comment by Phil Ringnalda #
2004-05-02 10:49:11

The acronym is one of my favorite parts of the whole thing. I don’t use asdf the way a lot of programmers seem to, so I’ve been missing out on that satisfying feeling of not having to move around the keyboard. All four or just three, it feels surprisingly good to type. SDF SDF SDF SDF SDF SDF SDF.

Trackback by Orcmid's Lair #
2004-05-03 20:35:27

Meet the New Boss

The worry-warting about forking is the funny part. I figure the only people who fret so much about that spend their lives forking other people’s code (it’s one of those look in the mirror to see who the enemy is kind of things). Or maybe never writin…

Name (required)
E-mail (required - never shown publicly)
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <del datetime="" cite=""> <dd> <dl> <dt> <em> <i> <ins datetime="" cite=""> <kbd> <li> <ol> <p> <pre> <q cite=""> <samp> <strong> <sub> <sup> <ul> in your comment.