It does beg the question, though (and I’m just trying to be a straight man here), “Why aren’t Atom + existing extensions good enough?” (using http://wellformedweb.org/CommentAPI/commentRss or even Dublin Core as an example)
(Nice Catch Kent!)
So yeah… Kind of left off some important pieces as to why It *IS* broken. Of course, in a follow-up comment I pointed Kent at the original post and suggested blocking out a solid 10 minutes to read all of the follow-up comments, thinking incorrectly that this, in and of itself, was a justifiable thing to do.
What I needed to do was sum things up into a couple short bullet points, or at worst, two or three sentences. But instead of correcting my mistake by creating the above, I am insted going to:
1) Create a Wiki entry on UnderstandingAtom (I’ll link to it when its ready) and let the community create the content. The reason: I’m not sure I know all of the reasons, nor even some of the RIGHT reasons. But I know people who do. As such, I am going to ask them to get the ball rolling, and then in the spirit of cooperation, let anybody willing to create an account with a simple username and password extend things from there.
2) Get out of the way.
Update: I did get the Wiki set up and ready to go, but as of yet haven’t had the time to prep things past the default DokuWiki Interface. Before too much time passes, suggesting the appearance that I simply forgot to get this done (definitely didn’t forget) you can access UnderstandingAtom.com (this links to the default, non-Trac root directory) and begin adding content at your own free will. I will be adding the proper ACL permissions and such this weekend, along with a slightly enhanced UI. But for now, this works :)
[original post cont.]
In fact, the ‘cooperation’ piece of the last sentence of point 1 is the part that I want to quickly extend from.
In the original post that started this all, my attitude was “why not let ‘good enough’ alone?’ That attitude changed, and led into the mentioned followed-up post. And now? I still believe that ‘good enough’ isn’t, but I also believe that David Powell, in the spirit of, as he put’s it — “because I care” — has helped showcase the fact the reason Atom exists in the first place is the very reason why the process used to develop the Atom specification was and is the correct way.
In terms of the considerations to the interoperability of running
code, thr:replies seems to beat atom:link in every way. It even
manages to be more concise (you don’t need the @rel), and you wouldn’t
need to put thr:count and thr:when into a namespace (namespaced
attributes confuse people).
<thr:replies type="application/atom+xml" href="http://www.example.org/mycommentsfeed.xml"; count="10" when="2006-02-20T00:00:00Z" />
<link rel="replies" type="application/atom+xml" href="http://www.example.org/mycommentsfeed.xml"; thr:count="10" thr:when="2006-02-20T00:00:00Z" />
I don’t really buy the justification that the attributes don’t matter,
so it is ok if they get lost btw. If I was using an API that didn’t
give access to the count attributes, I’d probably be a bit miffed, I’m
unlikely to say “oh it doesn’t matter cause they were only advisory,
I’ll just load the comments feed, parse the XML, etc, etc, instead”.
Yes, thr:count is derived, so it isn’t essential, but this doesn’t
mean that it isn’t useful. It is obviously useful, else it wouldn’t be
in the draft.
Regardless of the fact that in comments near the end of the original post my argument was in favor of the current usage of the atom:link element for the Feed Thread Extension, after reading this follow-up I realized “huh… you know what… I was wrong.” as his argument was and is absolutely spot on.
Aristotle agrees. (not in archive yet… will update this post with the link when it is.)
Update: I should note that nothing has been settled on this particular point as its still very much an open discussion. And, of course, this is an extension to Atom, not the Atom spec itself, which has already been through all of the above, ratified/approved, and recommended by IETF and the W3C. None-the-less, the fact that the open to anyone Atom community is continuing to improve things via extensions, using an open discussion format is the part of this I would hope to be the overall take away from the above.
And this is where I want to focus the point of this post.
The reason the Atom specification is such an important foundation to build upon has nothing to do with the fact that it has been ratified and standardized by IETF and recommended by the W3C, although this is certainly an important and necessary part of this. Instead, it’s because it has been conceived, written, discussed, argued, developed, discussed, argued, erased, re-written, discuess, argued, developed, erased a little, re-written, discussed, argued, developed, written some more, submitted, discussed, argued, a bit more erasing, a bit more writing, submitted, [and even a bit more of the same], accepted, approved, ratified, and finally….
Recommended as a standard to build against.
And all of the above happened in open discussion forums in which anybody who wanted to could comment, discuss, argue, blow a few gaskets if the need felt warranted, discuss, argue, comment, accept (+1), reject (-1), repeat.
Or maybe a better way to say it would be:
Atom is the result of building and breaking software, without building and breaking someones bank account so that we could all build software that doesn’t break, and as such build bank accounts that don’t get broken into so we can fix what should have never been built in the first place.
In metaphorical terms, an Atom represents a single unit. An entity. Or putting it in people terms, a person.
Atom was built by the people, for the people. The people represent power.
And thats the bottom line.
Power from the People, to the People, for the People.
Now go build great software!
(Thanks Atom Community! :)