Now that I have absolutely nobody's attention:
RE: [rss-public] Microsoft Feeds API Enclosure Test
For what it's worth, there will be updates to this API over time, so it is possible that we will have an API that makes the content available in Atom format, as well (or in the native format, though that's harder because it requires that we persist the original XML). This feedback is all extremely useful in helping us figure out what the right thing to do is.
Three things:
* The developers who are into using data feeds, or developing tools that generate data feeds, have all switched to Atom, even if that means from an internal "I prefer Atom, but I have to support RSS '2.0'" standpoint.
* You will get a TON of constructive feedback from the Atom development community.
* You will get a TON of destructive criticism from the RSS '2.0' 'community'.
[NOTE: Notice the difference between 'Atom development community' and 'RSS '2.0' 'community''. As already mentioned there is no *REAL* RSS '2.0' development community (thats not to suggest that *REAL* developers are not developing for RSS '2.0', and instead that the development discussions in the data feed community have shifted, primarily, to Atom, where as in the RSS '2.0' community all you will find (for the most part) is drama.]
Regarding:
This feedback is all extremely useful in helping us figure out what the right thing to do is.
I doubt it will take much more than a few weeks for you to realize that the Atom development community is all about serving the needs of the current and future data feed developer, no matter the format. If you want constructive feedback based on real world testing, you'll find exactly that in the Atom community.
That said, I personally feel that by converting over to an Atom-based format you will find that a lot of folks will be going out of their way to help make IE7 the best data feed browser available. Of course, without an official RSS '2.0' namespace, that would require the need to create one. But it seems that primary concern is not exact conformance, and instead general conformance. So creating a namespace that fills the namespace need shouldn't be all that hard of a pill to swallow, even if some of the RSS '2.0' 'Community' folks (or should I say folk?) feel otherwise. [UPDATE: Actually, come to think of it, there are several examples from reputable folks that showcase that you can easily map an RSS '2.0' feed to Atom without any loss in data quality. So in reality, I don't think you would need to worry about an RSS '2.0' namespace afterall. Even better!]
The result?
A better IE7 browsing experience = "the right thing to do."
To summarize:
Why even go down the
For what it's worth, there will be updates to this API over time, so it is possible that we will have an API that makes the content available in Atom format,
road?
Do it right the first time and you won't have to. While you most definitely *WOULD* need to update the API to provide native support for the Atom format, the same is not true about RSS '2.0'. Very few folks who's name is not Dave will be beating down your door to provide native RSS '2.0' support. To the contrary, in less than a years time a *TON* of folks *WILL BE* beating down your door for native Atom support.
Just do it now and save yourself the headache.
Need help?
Just ask the Atom development community, they'll be happy to help, I can promise you that. :)
Something to think about anyway :)
[UPDATE: Something else to think about... Ping the MSXML2 team and ask them how much of a pain in the a$$ it is to support a version of XSLT that pre-dates the final release of the spec. Okay, so the situation is not a 1-to-1 mapping, the ultimate end result more than likely is. Make the switch to the data feed format prefered by a significant majority of the development community and avoid the headache (and 'wallet-ache'!) of providing support for a long since dead-and-buried 'specification' in RSS '2.0' (.0.2? something like that anyway.) for the next 10 years.]
TrackBack URL for this entry:
http://www.xsltblog.com/xslt-blog-mt/mt-tb.cgi/1393
Listed below are links to weblogs that reference This Is A Call Out To All RSS Developers:
» still from still
[Read More]
Tracked on March 9, 2006 06:30 PM
I can see why Atom is a more powerful format, but I don’t really care that much for it. From a simple hassle standpoint, it’s a lot easier to put together an RSS feed than an Atom one. The Atom community is doing great things, but it has grossly underestimated the value of (1) striving for simplicity in implementation, (2) avoiding frequent changes to its standard.
In particular the API for posting via Atom is a huge hassle to implement compared to xmlrpc, even if the old xmlrpc style has some problems. Atom’s auto-discovery is nice, but it’s seldom implemented properly (or I couldn’t figure out how to do auto-discovery correcty).
Atom’s doing great things, but on my blog, all I do is provide an RSS2 feed. And frankly, that’s good enough. As for IE7 — as a web developer, I’m bitter enough about the pain Microsoft has inflicted on me, so I don’t see why I should go out of my way to help IE7 testing and adoption.
Atom is great, but it needs to be simpler and mature over time. And I don’t care about IE, or its users, so until it’s my job to “support” anything IE7, I won’t bother with it.
-Ken
Ken,
You’ve completely lost me on this one. Is it the tag and attributes names that throw you off? Last time I checked both formats use element names, attributes names, related values, and require that all of these are grouped in such a way as to be considered ‘well formed’. Of course, namespaces are often seen as something separate, but in reality namespaces are simply formalized XML attributes.
However, in the case of RSS, namespaces only apply to extensions, but I have yet to see an RSS ‘2.0’ feed in the wild that doesn’t use extensions, so the added ‘cost’ of the Atom namespace declaration couldn’t be the problem.
Or could it?
If yes, thats just a sad a$$ commentary… Since 99.100% of XML data feeds are machine generated, the notion that its just too much ‘effort’ to require such ‘excessive’ baggqage, and its for this reason that makes RSS ‘2.0’ more attractive than Atom makes absolutely no sense.
I’m not suggesting this is your reasoning for suggesting RSS is ‘easier to put together’, but I am striving as hard as I can to understand what could possibly be seen as easier about putting together an RSS feed over an Atom feed.
Wait, are you hand coding your data feeds?
If yes, why? If no… actually, even if yes, what could possibly be seen as easier in RSS? Both RSS and Atom have a ‘head’ like section with either ‘entry’ or ‘item’ elements for each entry. In regards to XML’s heirarchial nature, both formats are about as flat as you can get, and yet still have a tad wiff of heirarchy splashed into them. It couldn’t be that Atom requires a more complex data structure, because thats simply and absolutely not true.
Past this, I must admit you have me stumped. If its the fact that the Atom specification contains extensive details as to how to specify content type, etc… then you obviously don’t understand why this stuff is important. If this is the case, then some study time seems to be in due order. Arguing that “but the common person isn’t going to understand this” doesn’t fly either. The common developer, much less common person, doesn’t hand code their data feeds. Of course, as developers we are required to figure this stuff out and build machines that can accurately generate these data feeds for both us AND the common person.
With this in mind, the fact that a well defined specification exists goes an EXTREMELY long way into ensuring that each of us can create our own machines, yet subsequently rely on the notion that once we do, we will each be able to consume one anothers feeds, and do so with a reasonable amount of assurance that things will just work. This is the PRIMARY reason for all of this… With a specification to build against that has been developed by folks in whom have a proven track record of building industrial strength software (and as such, enough experience to understand what kinds of problems both have and can be encountered, building the specification to accomodate for these problems), we can rest assured that any problems we have with each of the machines that we build will be made known to us BEFORE we put them into the wild. And if they don’t become known before that happens, then we have something to point people to and state “see, here is where the problem is” and be able to do so with confidence that the problem will be fixed because of this.
Laziness of the developer is not justification for RSS ‘2.0’. As Mike Champion points out “worser is not better” in this case. RSS ‘2.0’ has REAL problems that go beyond just the intra and inter-rivalry drama. People encounter them on a daily basis, and its because of these problems that many times people get stuck in being able to advance their software projects. If we can’t have a certain level of expectation in the data feeds we consume, we are limited in regards to our ability to make technical progress. You might be Okay with that, but I’m not, and neither are ANY of the hacker folk that I ‘roll’ with. If we were to take such an attitude, we will have already lost before the game has really even got started.
So it can then be stated that we can cross you off the “willingness to help out” list?
Okay….
“Ken Kinder… Ken… Kind..er…”
“hmmm… Not finding a ‘Ken Kinder’ on the The > Atom < community ‘list’”…
… Oh wait, you’re not a part of the Atom development community, are you? I guess that would make sense as to why I am not finding your name, huh?!
Doh!
Okay then…
As was specified in my statement, for those who ARE a part of the > Atom dev-community < it CAN be stated that > THESE < developers both understand and care about the problems with RSS and are willing to help, wherever needed, to fix those problems.
It’s seems fairly obvious to me that:
and
With these two points in mind, I couldn’t have paid someone to showcase more perfectly my point:
Hey IE7/RSS team: Do ya see what I mean?
In particular:
Hey IE7/RSS team: Do ya see what I mean?
Yo Ken: 85+% of the world that accesses the internet at any given time, and/or any given day, does so using Internet Explorer. Maybe you personally can get away with ignoring this fact and be happy about it — [although, if your ‘tone’ of comment represents your general ‘happiness’ in life I sense that maybe you’re not all that happy of a person in general? I’m not accussing, as obviously I have no way to decipher who you are and what makes you happy via a couple paragraphs of text. But for what its worth, thats the impression I’m left with after reading your comments.] — but the rest of us who rely on these same 85+% of folks for a good portion of our paychecks [each week, every other week, each month, ?] we don’t have such ‘luxury’ as to be able to ignore IE7.
Huh? That must be a typo, cuz’ there’s not a single developer on this planet that could look at APP, then look at XML-RPC, and state
and have that be in reference to XML-RPC instead of APP.
XML-RPC is a broke-down White-Trash lawn-orniment who’s ride to the dump floored it in the other direction when it rounded the corner to see what it was they were being asked to take in transit.
Anyone who feels otherwise ISN’T a software developer, and instead (*please see point that starts “broke down…”)
Once again, Huh?
I guess maybe I’m still a bit disturbed by the whole “XML-RPC” incident, and as such am having a hard time clearing that “image” out of my head enough as to be able to think a bit more clearly on this one… but what are you talking about? What do you see that is different about RSS autodiscovery and Atom autodiscovery? Or are you suggesting the fact that there is a somewhat official Atom autodiscovery specification, but that its too difficult to understand, and therefore implement?
Maybe I need to spend some more time doing my homework, but from what I understand “Atom autodiscovery” has its roots in “RSS autodiscovery” both of which come from the general direction of Mark Pilgrim’s efforts, and both of which use the html/head/link element of html(4.x+)/xhtml(1.x+) and its related attributes to specify an alternate data feed, or collection there-of, for any given html/xhtml page and/or website/blog in general.
With this in mind, and in thinking through the space of time in which I began to use products that implemented support for autodiscovery, I don’t think I have ever encountered a situation where it was implemented incorrectly, or at very least the machines built to look for autodiscovery did so taking into account that it was possible they might not conform exactly to what is expected.
Then again there have only been a few times that I have gone to someones blog in which an auto-discovery link didn’t make itself known on my autodiscovery “radar” screen. In these cases I either assumed they didn’t have one set into place, or if I did look, it was to discover that they didn’t have one, therefore leading me towards a somewhat lazy habit of believing “huh… I guess they don’t have a data feed for their site/blog/web page”. I am trying to remember and subsequently count all of the times that this has happened, and it seems to me that I can do this without the need for taking off my shoes. NOTE: For those of you who have ‘<’ or ‘>’ the human average of 10 fingers/thumbs/combination-thereOf this would mean that the times in which I expected to find an auto-discovery link, yet did not find one, is < 10 times in total for the last 3 or so years. Thats not very many, and I can promise you… Three years worth of expectations represents a TON of expectations.
Ken, I have to admit I am having a tough time understanding the purpose and point of MOST of your comment block, but none-the-less I do appreciate the time you have taken to provide these comments. Time is a limited and valuable resource, so thanks for sharing some of yours with me and those in which might take some of their own time to read these comments.