As much as I appreciate
Longhorn’s support, I really would appreciate it they did
not include Atom 0.3 support. By the time Longhorn comes out,
I have every intent to make Atom 0.3 feeds as rare as Atom 0.2
feeds are now; which is to say, practically non-existent.
For now, however, Atom 0.3 feeds continue to validate. I
don’t believe I have broken anything (and have 600
testcases
backing me up on this), but I will say this: while I do have checks
in place ensuring that no Atom 0.3 unique elements are contained in
Atom 1.0 feeds, I haven’t been so careful about ensuring the
reverse checks are in place. This means that the Feed
Validator has become slightly more liberal in interpreting Atom 0.3
compliance.
In early August, I plan to have the Feed Validator start issuing
warnings whenever it encounters an Atom 0.3 feed. It already
is issuing warnings on the use of Atom’s
application/atom+xml mime type by anything other than
an Atom 1.0 feed.
Possibly as early as October, and certainly no later than the
end of the year, these warnings will be converted over to
errors.
That would break a lot of users though. Individual installs of .Text or older versions of MT would not work if that’s the case. Lots of people don’t want to keep tweaking and upgrading their blog software.
If Longhorn wants its XML syndication API support to be relevant it should support all the major syndication formats. Today, Atom 0.3 is a major syndication format that is exposed by millions of websites mostly thanks to Blogspot/Blogger & LiveJournal.
If the majority of Atom 0.3 feeds have switched over to Atom 1.0 in the Longhorn timeframe (which isn’t far fetched) then there is a good reason for the Longhorn XML syndication platform to drop support for it. Until then I’m not sure there is a good case for not supporting Atom 0.3
I just IMed with Sean about this post so it is on the Longhorn RSS team’s rader.
Even if 90% of Atom feeds were converted, why break support for 10% if the engineering work were already planned/completed? Seems to me like a good thing for users and developers to keep supporting the older format.
Sam Ruby: "In early August, I plan to have the Feed Validator start issuing warnings whenever it encounters an Atom 0.3 feed. It already is issuing warnings on the use of Atom’s application/atom+xml mime type by anything other than an......
One time, Mozilla Thunderbird was having an issue with feed processing dispatch, because it was using a regex (doesn’t anymore...) to search for NS declarations. Feedburner started putting USM atom:link elements in RSS feeds, and it was breaking Thunderbird’s naive regex. Thunderbird got patched, but the Feedburner guys turned off that element for Thunderbird clients.
In TW3, all main-feeds are Atom 1.0. I converted as soon as the new spec was out.
Here the other day, I remembered that I have unique Atom documents for each weblogentry, which only contain that entry.
Those are still Atom 0.3, but I’ll try to fix it ASAP.
Keep up the very good work, Sam & Mark!
Lots of people don’t want to keep tweaking and upgrading their blog software.
At some point in the future, I imagine new tools will provide poor, if any, support for Atom 0.3. In blog years, Longhorn is still a long, long way away.
In many cases, updating the feed format is simply a matter of changing a template.
Let’s revisit this post when Longhorn ships. As Dare indicates, getting a few of the larger providers to convert will make a big difference. For many of the others, I’m hoping that advocacy and continued support by the Feed Validator will do the trick. I’m confident that if people knew that Longhorn would not support Atom 0.3 that that would also provide significant incentive.
Now that Atom is almost a standard, it’s time to make the change. The RSS feeds go away tonight. If you request them, you’ll get a 410 Gone and a stub entry telling you to switch to the Atom feed. Sam Ruby’s announced a timetable for transitioning...
deusx : Sam Ruby: Atom 0.3 Denouement - “Possibly as early as October, and certainly no later than the end of the year, these warnings will be converted over to errors.” There goes my book :)...
To prevent the mess of incompatible versions that is rss, Atom versions prior to 1.0 should be unsupported, right? Hence there was never a need for backwards compatibility or anything (which I assume there will be in atom 1.1).
It’s no big deal for aggregators that currently support 0.3 to support 1.0 in addition to 0.3 (instead of switch to just support 1.0), but for any new Atom implementations, dealing with a single spec would be much better.
Sure, atom 0.3 is widely implemented, but the vast majority of these implementations are from sites like Blogger or LiveJournal, which can easily be switched to 1.0
By the time Longhorn comes out in 3 years or so, there shouldn’t be much 0.3 feeds out there anymore, and not being supported by Longhorn should force these remaining ones to update to 1.0 as well.
Sam Ruby: As much as I appreciate Longhorn’s support, I really would appreciate it they did not include Atom 0.3 support. [cut] In early August, I plan to have the Feed Validator start issuing warnings whenever it encounters an Atom 0.3...
Randy: The last I heard, RSS 0.9x was perfectly appropriate and made not one bit of difference. That being said, if this turns out to be the expressed consensus of the RSS 0.9x community (read: some subset of Dave Winer, UserLand and/or the RSS Advisory board), I would gladly make the change.
It looks like WordPress is going to continue supporting 0.3 while adding 1.0 support, that’s what our users are asking for. From our point of view we’re just producing 5 types of feeds for every single item rather than 4 like we do now.
If you anticipated erasing 0.3 from the history books, you and Mark shouldn’t have lobbied so hard for so many tools to incorporate it over a year ago. What’s done is done though.
If you anticipated erasing 0.3 from the history books, you and Mark shouldn’t have lobbied so hard for so many tools to incorporate it
Wow. You’re missing the point so utterly and completely that it makes me wonder if someone in the my-horse-and-buggy-works-for-me cult isn’t pretending to be Matt Mullenweg to have a little fun with us.
The real Matt Mullenweg once said, “[O]ne thing that will never change is our commitment to web standards and an unmatched user experience. That is at the forefront of our mind with every change we make...” [source]
Atom 1.0 will shortly be an IETF RFC, which makes it as much of a web standard as HTTP. Atom 0.3 was just some guys (and gals) dicking around on a wiki. As it turned out, some guys dicking around on a wiki were able to produce a relatively decent standard, but that isn’t saying much given the competition. Atom 1.0 is a great standard, worthy of the label and worthy of being pushed by standards advocacy groups like WaSP (which you also point to from Wordpress.org’s about page, with the link text "standards").
Certainly worthy of more than a grudging consideration by such standards-loving — and I use this word with the utmost respect — pedants as the Wordpress developers.
I can’t figure out if the cluestick needs to be broken out or not on this one. I feel like I’m missing something, but I can’t figure out what it is.
If Atom 0.3 was just some folks “dicking around”, and then a bunch of people went off and built tools around it, then maybe some considerations should be made for the users. Not everyone is a developer or wants to write code (or do configuration) around blogging tools. Should hosting service providers like Blogger and LiveJournal update their infrastructure? Absolutely! Seems like a great idea. But what about an independent developer that rolled their own blogging engine supporting Atom 0.3? Or worse yet, what about a user that installed a version of MT or .Text on their own box that doesn’t support Atom 1.0? Should they really have to upgrade if they don’t want to?
Should you encourage people to move to Atom 1.0? I don’t see why not. But I don’t understand why you have to “break” people’s feeds in the validator just because it isn’t the new hotness that is Atom 1.0.
With all due respect to those involved, I think that this is a disservice to the users that embraced Atom 0.3. Without the success of Atom 0.3, would there even be any interest in Atom 1.0?
I posted the following comment on Sam Ruby’s blog but wanted to share it here also. I can’t figure out if the cluestick needs to be broken out or not on this one. I feel like I’m missing something, but......
SOAP substitute? Bill: “Atom, RSS and the Atom [protocol] could disrupt SOAP and WS” Congrats Noniko! Noniko: “my 3rd How-to book was published. It’s on Sun Java Studio Creator” Noniko’s books Noniko has written how-to books on Eclipse, Netbeans...
The proper response at this point, after two years in which Atom proponents repeated the nine-versions-of-RSS FUD as often as breath allowed, is to enjoy watching Atom suffer through its own multi-version hassle.
But if you can get away with erroring 0.3 out of existence, I hope you succeed.
I had the same understanding as Luke, that this was all part of the plan. Correct me if I’m wrong, but I don’t believe Mark and Sam lobbied for tool developers to add support, merely to experiment. As Mark put it, 0.3 was dicking around, and quite a few people made a point of saying this isn’t the final version - if you implement now, be prepared to upgrade. I can’t be bothered searching the archives, but quite a few people did feel Blogger had jumped the gun with their implementation, which I think was the one which led to the impression that 0.3 was any kind of official specification.
Pragmatically speaking I think it’ll be a non-issue - the majority of aggregator developers are likely to have support for Atom The Specification in a matter of weeks. Most aggregators are seriously liberal anyway, so Atom 0.3 passed off as 1.0 isn’t likely to trigger an error message. On the publishing tool side, again we’re only probably talking a few months to update for even the biggest players. Ok, the cost of adding support for 1.0 as well as 0.3 is negligible compared to replacing 0.3 with 1.0. For a while we’ll probably see quite a few sites with two irritating Atom icons rather than one, together with confusing autodiscovery. But over the space of maybe a year or so, as people naturally trim the cruft from their sites/code, the 0.3 support will evaporate.
Rogers - there is a significant difference, in that the multiple versions of RSS in the ‘simple’ branch were always sold as backwards-compatible, even though they usually weren’t if you looked closely. The Atom development has been intentionally not backwards-compatible. It’s closer to what Beta used to mean - you wouldn’t usually want to run MS Dancing Paperclip Beta when the release version became available. For the end user, it is better that 0.3 gets errored out of existence.
But I don’t think anyone around Atom needs to put in too many cycles on helping the changeover, I reckon it’ll happen of its own accord. As and when Longhorn appears is will undoubtedly have support for Atom 1.0, even if it also supports 0.3. Any sane developer that bothers to look at the specs will realise they’re wasting their time supporting 0.3 (and quite possibly RSS, depending on the timescale).
Longhorn (hearts) Atom, too Yes, we love Atom, too. :) For the past couple weeks, we’ve been working full-time on implementing the RSS platform features in Longhorn. Of the many interesting features the development team has been...
Rogers: care to comment on Randy's recommendation?
My prediction is that when Longhorn ships, the number of actively maintained RSS 0.9x feeds will greatly exceed the number of actively maintained Atom 0.x feeds.
And I still won’t know if the RSS 0.91 channel element requires an image.
Why do you care if Matt and other software developers continue to produce Atom 0.3 format feeds, and if aggregator developers continue to support them? What’s the harm? Even more to the point - why should they care?
Should you encourage people to move to Atom 1.0? I don’t see why not. But I don’t understand why you have to “break” people’s feeds in the validator just because it isn’t the new hotness that is Atom 1.0.
This argument is a paper tiger. Nothing that Sam or Mark can do on the validator will “break” a feed. If an independent developer wrote software tools to publish and consume Atom 0.3 feeds, great! Guess what? They will continue to work! Now, if they want to continue to work on the software going forward they have a choice to make: keep using the pre-release spec software or take the time to upgrade it. This is not a big deal and is the price you pay for developing at the bleeding edge. The whole point of having a validator is to check your code for compliance. No one ever said 0.3 was any kind of a frozen specification and the developers assumed that risk. In fact, I’d argue that implementing a non-frozen spec is the same as using beta software and if you want to ensure your feed’s continued validity you’ll update your apps to conform to the final version of the specification. Really, what’s all the griping about?
Mark: Will the Universal Feed Parser drop support for Atom 0.3?
No. UFP supports every version of RSS, plus every version of Atom (including 0.1 and 0.2), Hot RSS, CDF, and every bastardized combination you can imagine.
This should not come as a raging shock to anyone. UFP’s goals are significantly different than the goals of the Feed Validator. Sam runs the Feed Validator now, and he has made it quite clear that he will deprecate any standard that the appropriate authoritative body claims should be deprecated. The RSS Advisory Board has made it quite clear that older versions of RSS are not deprecated, so the validator continues to validate them as best it can. It is my understanding that the Atom Working Group wanted Atom 0.3 to be deprecated, and it appears that Sam is acting on that consensus. If my understanding is wrong, and the Atom Working Group has decided (or decides later) that Atom 0.3 should “live on”, then Sam would be wrong to deprecate it in the validator. It’s really that simple.
The only thing the board has done to discourage RSS 0.9x is to advocate RSS 2.0. If the older versions continue to serve a purpose for implementors and publishers, I personally don’t see any enthusiasm for telling them to stop finding them useful. Dave Winer concurred back in 2003.
It’s cooked and ready to serve. There are a couple of IETF process things to do, but this draft ( HTML version ) is essentially Atom 1.0. Now would be a good time for implementors to roll up their sleeves and go to work. Here’s a comparison of...
It’s likely that most publishing and aggregation apps will make the transition in the regular course of their upgrades, possibly sooner via a plugin. But there’s virtually nothing the end user has to do, aside from maybe modify the links to their...
Now I notice that versioning isn’t handled with the namespace, but what the heck. I can see warnings about validating these feeds to point out that the 0.3 version is deprecated, but I don’t know why you wouldn’t assess (i.e., validate) it at what it purports to be.
I would like to see verifiers and assessment tools without politics, thank you very much.
Atom team wants Microsoft to not support the old format
Hmmm, the Atom team doesn’t want Microsoft to support the old Atom format. That goes against our culture of supporting all the formats that are currently publishing....
With the impending release of Atom 1.0, its creators are taking the unusual step of disowning version 0.3, which has been widely implemented by Google, Six Apart, and other developers. Sam Ruby will revise the Feed Validator to reject all 0.3 feeds...
There’s a big stink about the future of Atom 0.3. Some folks are claiming that the Atom working group is trying to disown the format. That is silly. Atom 0.3 is not being disowned, it’s being deprecated. Consider Atom 0.3 an alpha version of 1.0...
The Atom guys want MS to not support Atom 0.3 in Longhorn. Hmm - maybe they should have made a bigger stink when Google deployed it to Blogspot. I’m not about to yank support for 0.3 out of BottomFeeder - 0.3 is guaranteed to live a long time due...
A question—two days late—for Mr. Mullenweg. What’s the advantage of leaving Atom 0.3 support in a future version of Wordpress? Unless you intend for mikemariano.com/feed/atom/ to continue to serve Atom 0.3 feeds, you’ll be breaking people’s feed URLs anyway. And I doubt putting Atom 1.0 into a mikemariano.com/feed/atom1.0/ ghetto will please users that do want to use the new standard.
I don’t doubt that there are Wordpress users that want to cling to Atom 0.3, but that’s what a plugin—or staying with Wordpress 1.5—would be for.
Dare - you used to provide an Atom 0.2 feed. Now I see that you provide an Atom 0.3 feed. Notice any problems in the change over?
I think the disconnect here is the words “all of a sudden”. Where did that come from? I could perhaps understand the reaction if this were in fact what was being advocated, but to insert that into this discussion, and then react emotionally to that which you created is blatantly unfair.
When is Longhorn Vista likely to become released? What is the landscape likely to be in terms of supported feed formats deployed at that time? If I can point to an actively maintained RSS 0.9 feed, will Microsoft support it?
The notices on the Atom drafts have been there for quite some time.
If anything, this has been a very measured, very deliberate, and very public process.
Dare, I was under the assumption that most subscribers wouldn’t notice anything following an upgrade. Feed readers that understand Atom 1.0 shouldn’t hiccup when an Atom 0.3 suddenly becomes 1.0. Feed readers that don’t understand Atom 1.0 may have a problem, but for most users it may just mean time for an upgrade.
What about users that don’t want to upgrade their feed reader? There are tried and true RSS feeds waiting for them.
I say this as a subscriber that is going to let the Bloglines Plumber do all the hard work, but as a weblogger I don’t see why I have to give Atom 0.3 a permanent home at mikemariano.com/feed/atom/ just to satisfy the recalcitrant.
This is from a guy that doesn’t understand the specs to any great degree. My primary use of web syndication is via Firefox’s Live Bookmarks. In many cases, I have subscribed to the Atom 0.3 feeds on many weblogs.
Now if blogger A changes his format from Atom 0.3 to Atom 1.0, will my Firefox Live Bookmark stop working?
Yup. I just tried to subscribe to your feeds and guess what? “Live Bookmark feed failed to load”. Congratulations, you’ve just lost subscribers...
You know, I realize you guys are excited to get your specification published and all, but shouldn’t you wait until the specification is actually published (not NEARLY published) and a decent number of aggregators and blogging software can actually handle Atom 1.0 feeds before you encourage everyone to deprecate Atom 0.3 feeds?
Because nobody ever seems to believe such a thing is really possible: [link]
Not another “here’s one feed in 13 formats” or a legacy URL, if you don’t parse 0.90 you don’t parse three of the five The Perl Review feeds.
Something to consider before encouraging people to ship aggregators that don’t parse 0.3:
Typically, aggregators refuse to subscribe to feeds they can’t parse (so they don’t wind up continuously reparsing an HTML page, hoping it will turn into RSS, something that’s likely to be needed when WV introduces a few hundred million people to the idea of feeds).
While Blogger can automatically republish blogs hosted on Blog*Spot, they can’t automatically republish all blogs, because they don’t have a stored FTP password for everything hosted offsite.
Subscribing to something dead, hoping it will come back, is a primary use case for feeds: I’ve been subscribed to the atomenabled.org feed for 10 postless months (during which it had incorrect autodiscovery, even though Blogger had long since corrected the problem), waiting for something new.
No matter how long the span between Blogger flipping the Atom 1.0 switch and WV shipping, there will still be Blogger-produced Atom 0.3 feeds around that people will want to subscribe to, waiting for a new post. What’s better, for WV to allow a hundred million people who don’t grasp the idea of feeds to subscribe to HTML (and PDF, and GIF) URLs, or for it to parse 0.3 feeds while it waits for the producer to get with the program?
orcmid: “For one thing, I’ve got a legacy potfull of Atom 0.3 feed files in persistent form, and I’m not about to alter them if I could. [...] I would like to see verifiers and assessment tools without politics, thank you very much.”
In itself that’s a political position, insofar as it shows some self-interest. There are a lot more versions of Atom than 0.3. How many do you think should be supported?
There’s some amount of hyperbole and inflammatory language doing the rounds about this at the moment. Perhaps there’s something about syndication technology that brings out one’s inner tabloid editor.
If Sam’s policy that says the validator supports what the format creators deem should be supported (personally I didn’t know that), then so be it. In retrospect, 0.3 support could arguably have been dropped some time ago. Otherwise, this seems to be assumed obligation - if it’s that important a service, write your own validator.
If history is any guide, it will be a long time before Windows Vista is released for general availability. Once shipped, Microsoft will be in a position where they will be expected to support it for a long time. That being said, I do believe that attempting to support every version of RSS, and every snapshot of Atom, as well as CDF, as the Universal Feed Parser does, is a very self-consistent and defensible position. However, that is not the position that I have heard for Vista. Instead, I see a strategy of attempting to support the prevalent (or expected to be prevalent in the case of Atom 1.0 as current adoption is essentially nil) formats at the time Longhorn ships.
If so, I feel that they should be aware of the statement I lead this post off with, namely :
I have every intent to make Atom 0.3 feeds as rare as Atom 0.2 feeds are now; which is to say, practically non-existent.
It would be nice if the open-source were packaged and posted as releases rather than having we CVS-challenged folk have to figure out how to get it that way.
The validator did validate (and is proud to announce that it validates) Atom 0.3. So there seems to be no doubt what a valid Atom 0.3 feed is. Why not simply continue that? There is a big difference between refusing to validate and simply noting that the submitted feed uses a deprecated version.
Finally, the achievement of Proposed Standard status on the IETF Standards track is not exactly any assurance that there will be no changes in moving up the line to Draft Standard and then IETF Standard.
By politics I mean making these things prescriptive rather than descriptive. That’s not exactly in tune with how voluntary standards are handled, in my book. Specifying a particular conformance in some procurement, or in evaluating a product for adoption, that’s fine. But why not let the community work it out and get the policy position out of the validator?
It would be nice if the open-source were packaged and posted as releases rather than having we CVS-challenged folk have to figure out how to get it that way.
Done. If I did it right, it will be updated daily.
The validator did validate (and is proud to announce that it validates) Atom 0.3. So there seems to be no doubt what a valid Atom 0.3 feed is. Why not simply continue that? There is a big difference between refusing to validate and simply noting that the submitted feed uses a deprecated version.
Truth be told, this support is deteriorating rapidly. Take a random Atom 1.0 feed, and change the namespace to the one that Atom 0.3 uses, and see what you get. None of the new additions to Atom 1.0 will be flagged. As Atom 1.0 now treats the href attribute as optional on link elements, this check no longer is being made for Atom 0.3 feeds.
Finally, the achievement of Proposed Standard status on the IETF Standards track is not exactly any assurance that there will be no changes in moving up the line to Draft Standard and then IETF Standard.
While changes are not expected, I fully intend to track to any changes.
By politics I mean making these things prescriptive rather than descriptive. That’s not exactly in tune with how voluntary standards are handled, in my book. Specifying a particular conformance in some procurement, or in evaluating a product for adoption, that’s fine. But why not let the community work it out and the policy position out of the validator?
At some point, I wish to stop maintaining validator support for Atom 0.3. Instead of allowing the support to increasingly deteriorate, I would like to flag the feeds for a period of time, and ultimately remove the support.
This can create an opportunity for an aspiring young validator out there. If anybody is willing to host andmaintain a validator which supports Atom 0.3, I’m willing to point to it (or them) both in the deprecation announcement and in the specific error message that will be produced when the Feed Validator encounters such feeds.
I know that there is at least one such validator out there that could serve this purpose.
Feed Validator Ever since the the IETF Atom syndication format specification has been declared ready for implementation (more), the demand for Atom 1.0 support by the Feed Validator has been high. As progress on implementing the Atom 1.0 test cases...
An Hour with Cindy SheehanMatt Drudge ran anewsfla...
An Hour with Cindy SheehanMatt Drudge ran anewsflashtoday on Cindy Sheehan, the military mom whose 24-year-old son’s death in Iraq spurred her to protest the war.Sheehan made international news last week when shevisited Crawford, Texaswith...
(I could have sworn I did this earlier today! ;-). A new feed spec is announced, this time by Tim Bray: Atom 1.0: "It’s cooked and ready to serve. It doesn’t have an RFC number yet, but this is officially Atom 1.0 (HTML here). Here’s a comparison of...
Lately, there’s been some noise about Atom 1.0. Sam Ruby wants to phase out Atom 0.3 thoroughly in favor of the new spec, and there’s now a few early-adopters who’ve started converting their feeds. Sadly, fully compliant Atom 1.0...
UFP supports every version of RSS, plus every
version of Atom (including 0.1 and 0.2), Hot RSS, CDF,
and every bastardized combination you can imagine.
The version of the UFP linked from feedparser.org (version 3.3, dated July 2004) doesn’t seem to handle Atom 1.0. Is there a later version available from somewhere else that supports 1.0?
Is it just me or do others think that it’s rather devalueing to call the open work on the Atom format in the Wiki just dicking around? When we were just dicking around, people like Mark called Atom the best thing since sliced bread and called for...
From Phil Ringnalda, I learn that Ben de Groot has been working to see if Atom 1.0 support will come out in WP 2.0. Apparently, WP 2.0 won’t support Atom 1.0, and as Sam Ruby promised he would, the feed validator will now declare Atom 0.3...
WordPress looks set to ship its next version with an Atom feed that the feedvalidator will just flatly say is too outdated to even bother looking at. Interesting....
That time has arrived. Where there previously was a general warning, you now get specific, element by element, and attribute by attribute indication of what needs to change to make your Atom feeds conform to RFC 4287. This is also helpful. The goal...
[more]
Apparently, 2.0 is going to ship with an invalid feed on account of Atom 0.3 is no longer a valid or supported spec and Matt is refusing to support the new spec in the next release, or explain his reasons for this decision. I was all ready to get,...
The version of the UFP linked from feedparser.org (version 3.3, dated July 2004) doesn’t seem to handle Atom 1.0. Is there a later version available from somewhere else that supports 1.0?
Atom 1.0 support was checked into CVS in October. I’m working on updating the documentation.
A few weeks ago Phil Ringnalda posted to say that WordPress 2.0 would ship with Atom 0.3 feeds. Atom 1.0 (RFX 4287) has been done for a good five or six months. Sam Ruby gave notice in July that 0.3 feeds would receive warnings from the feed...
