It’s just data

Atom 0.3 Denouement

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 test cases 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.

Posted by Randy H. at

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.

Posted by Dare Obasanjo at

Speaking of Blogger/Blogspot and Atom 0.3, that reminds me never ascribe to malice that which can adequately be explained otherwise

Posted by Dare Obasanjo at

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.

Posted by Randy H. at

ATOM 0.3- end of life?

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......

Excerpt from Randy Holloway Unfiltered at

Given how wide spread Atom 0.3 has become I think you’ll have hard time getting everyone to switch over to Atom 1.0.

Posted by Joseph Scott at

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.

Posted by Robert Sayre at

“The avalanche has begun, it’s too late for the pebbles to vote.”

Atom 0.3 is an ideavirus, good luck undoing it.

Posted by Scott Hanselman at

Not directed to Scott at all, because basically everyone does it, but why are web geeks so attracted to self-help literature?

I know it’s rebranded as “43 things”  or “getting things done” or “unleashing the ideavirus” (unleashing your inner Dale Carnegie), but damn, it creeps me out.

Posted by Robert Sayre at

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!

Posted by Henrik Lied at

Is there anywhere a short list of the changes between 0.3 and 1.0 formats? The things relevant for implementors and testers?

Posted by Rijk at

Randy:

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.

Dare:

I just IMed with Sean about this post so it is on the Longhorn RSS team’s rader.

Thanks!

Joseph, Scott:

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.

Rijk:

The simplest thing to do is to change the namespace on your feed element, and let the feed validator tell you what you need to change.

Posted by Sam Ruby at

The Atomic Transition

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...

Excerpt from More Like This WebLog at

Sam Ruby: Atom 0.3 Denouement

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 :)...

Excerpt from HotLinks - Level 1 at

Could I recommend warnings for RSS 0.9X too? This might help RSS client programmers kick the 0.9X bucket.

Posted by Randy Charles Morin at

If you want people to stop using Atom 0.3 don’t forget to update the atomenabled website. Namely this section here: [link]

Posted by Sérgio Nunes at

I thought this always the plan?

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.

Posted by Luke Hutteman at

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...

Excerpt from The RSS Blog at

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.

Sérgio: fixed, thanks!

Luke: absolutely.

Posted by Sam Ruby at

some subset of Dave Winer

You mean Dave Winer comes in six-packs now?  Like Zaphod Beeblebrox?

Posted by Mark at

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.

Posted by Matt at

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.

Posted by Mark at

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?

Posted by Randy H. at

Sam Ruby: Atom 0.3 Denouement

[link]...

Excerpt from del.icio.us/yohei at

Atom 0.3-- what am I missing?

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......

Excerpt from Randy Holloway Unfiltered at

del.icio.us links [July 20, 2005]

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...

Excerpt from Blogging Roller at

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.

Posted by Rogers Cadenhead at

Mark: Will the Universal Feed Parser drop support for Atom 0.3?

Posted by Henri Sivonen at

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).

Posted by Danny at

Longhorn loves ATOM

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...

Excerpt from Paul Mooney at

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.

Posted by Sam Ruby at

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?

Posted by Got Freed Up Salon at

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?

Posted by Christian Romney at

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.

Posted by Mark at

“care to comment on Randy’s recommendation?”

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.

Posted by Rogers Cadenhead at

Atom 0.3 vs. Atom 1.0: End Users as Collateral Damage

... [more]

Trackback from Dare Obasanjo aka Carnage4Life

at

Atom 1.0

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...

Excerpt from Planet XML at

Feed the Feeds

Posted by Shelley at

Atom de 0.3 vers 1.0

Enfin un article synthétique pour se faire une idée rapide de la conversion Atom 0.3 vers Atom 1.0. Ouf ! Surtout après avoir lu ça ... :-p......

Excerpt from Just call me Pep. at

Upgrading from Atom 0.3 to Atom 1.0

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...

Excerpt from Planet RDF at

I think there is a serious misunderstanding about “deprecated” and the voluntary nature of industry standards on this part of the planet.

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.

For another thing, they all start off with

<feed xmlns="http://purl.org/atom/ns#" version="0.3" xml:lang="en-US">

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.

Posted by orcmid at

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....

Excerpt from Scobleizer: Microsoft Geek Blogger at

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...

Excerpt from Workbench at

I would like to see verifiers and assessment tools without politics, thank you very much.

[link]

Posted by Mark at

Deprecating Atom 0.3

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...

Excerpt from snellspace.com at

Just deal with it

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...

Excerpt from Smalltalk Tidbits, Industry Rants at

Well, where I come from someone who dicks around is called a dick. But then a dick who can’t stand listening to his own words is not really a dick because a dick can’t speak nor hear.

Posted by Don Park at

Remarks

Some remarks on different topics....

Excerpt from Anne’s Weblog about Markup & Style at

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.

Posted by Mike Mariano at

Mike Mariano,
  So you want people to upgrade their instance of WordPress and all of a sudden break everyone who was subscribed to their Atom 0.3 feeds? 

I guess those end users would just be the collateral damage in this phase of the syndication format wars.

Posted by Dare Obasanjo at

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.

Posted by Sam Ruby at

If I can point to an actively maintained RSS 0.9 feed, will Microsoft support it?

Don’t forget CDF.  [link]  It is Microsoft’s format, after all.

Posted by Mark at

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.

Posted by Mike Mariano at

Mark Pilgrim's comment on "Sam Ruby: Atom 0.3 Denouement"

“Atom 0.3 was just some guys (and gals) dicking around on a wiki.” Is this a famous quote now?...

Excerpt from del.icio.us/dsandler at

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?

Posted by Jeff Schiller at

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? 

Disappointing.

Posted by Jeff Schiller at

point to an actively maintained RSS 0.9 feed

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:

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?

Posted by Phil Ringnalda at

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.

Posted by Bill de hOra at

Phil:

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.

Bill:

I’m confident that the “hyperbole and inflammatory language” will pass.

As to the “assumed obligation”, let me cite the following precedents and announcements:

Oh, and there is no need to write a new validator, though of course one is always welcome to do so.  The Feed Validator is open source.

Posted by Sam Ruby at

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?

Posted by orcmid at

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.

Even worse, the help messages are changing.  Examples: AtomLinkNotEmpty, ContainsUndeclaredHTML, DuplicateAtomLink, InvalidNamespace, and NotBase64.

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 and maintain 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.

Posted by Sam Ruby at

Conversion

Comme prévu, Atom 1.0 devrait rapidement remplacer Atom 0.3 (y compris dans ce blog). Apparemment, il n’y a pas de quoi en faire un plat. Quoique !...

Excerpt from .Conforme at

Sam, just tell me when.

Posted by Randy Charles Morin at

DasBlog 1.8 will/does produce Atom 1.0 valid documents

... [more]

Trackback from ComputerZen.com - Scott Hanselman's Weblog

at

Getting ATOM

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...

Excerpt from Paul Mooney at

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...

Excerpt from jing on bang at

Atom 1.0

New Atom 1.0 feed....

Excerpt from Musings at

Atom 1.0 specs published

(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...

Excerpt from Alex Barnett blog at

Atom 1.0

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...

Excerpt from Sporkmonger at

Mark Pilgrim wrote:

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?

Posted by amk at

just "dicking around in a wiki"?

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...

Excerpt from Python Desktop Server Weblog at

Why No Atom 1.0 in WP 2.0?

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...

Excerpt from Geof's Relentless Kvetching About WordPress at

Your forthcoming feed errors

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....

Excerpt from phil ringnalda at

Nudging forward

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]

Trackback from Sam Ruby

at

57 varieties

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,...

Excerpt from wordpress wank at

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.

Posted by Mark at

WordPress is a Mess

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...

Excerpt from Thought Torrent at

VIRUS REMOVAL

Is Your Computer Sluggish or Plagued With a Virus? – If So you Need Online Tech Repairs
As a leader in online computer repair, Online Tech Repairs Inc has the experience to deliver professional system optimization and virus removal.Headquartered in Great Neck, New York our certified technicians have been providing online computer repair and virus removal for customers around the world since 2004.
Our three step system is easy to use; and provides you a safe, unobtrusive, and cost effective alternative to your computer service needs. By using state-of-the-art technology our computer experts can diagnose, and repair your computer system through the internet, no matter where you are.
Our technician will guide you through the installation of Online Tech Repair Inc secure software. This software allows your dedicated computer expert to see and operate your computer just as if he was in the room with you. That means you don’t have to unplug everything and bring it to our shop, or have a stranger tramping through your home.
From our remote location the Online Tech Repairs.com expert can handle any computer issue you want addressed, like:
• - System Optimization
• - How it works Software Installations or Upgrades
• - How it works Virus Removal
• - How it works Home Network Set-ups
Just to name a few.
If you are unsure of what the problem may be, that is okay. We can run a complete diagnostic on your system and fix the problems we encounter. When we are done our software is removed; leaving you with a safe, secure and properly functioning system. The whole process usually takes less than an hour. You probably couldn’t even get your computer to your local repair shop that fast!
Call us now for a FREE COMPUTER DIAGONISTIC using DISCOUNT CODE (otr214428@gmail.com) on +1-914-613-3786 or chat with us on www.onlinetechrepairs.com.

Posted by otr214428 at

Problem: HP Printer not connecting to my laptop.
I had an issue while connecting my 2 year old HP printer to my brother’s laptop that I had borrowed for starting my own business. I used a quick google search to fix the problem but that did not help me.
I then decided to get professional help to solve my problem. After having received many quotations from various companies, i decided to go ahead with Online Tech Repair (www.onlinetechrepairs.com).
Reasons I chose them over the others:
1) They were extremely friendly and patient with me during my initial discussions and responded promptly to my request.
2) Their prices were extremely reasonable.
3) They were ready and willing to walk me through the entire process step by step and were on call with me till i got it fixed.
How did they do it
1) They first asked me to state my problem clearly and asked me a few questions. This was done to detect any physical connectivity issues with the printer.
2) After having answered this, they confirmed that the printer and the laptop were functioning correctly.
3) They then, asked me if they could access my laptop remotely to troubleshoot the problem and fix it. I agreed.
4) One of the tech support executives accessed my laptop and started troubleshooting.
5) I sat back and watched as the tech support executive was navigating my laptop to spot the issue. The issue was fixed.
6) I was told that it was due to an older version of the driver that had been installed.
My Experience
I loved the entire friendly conversation that took place with them. They understood my needs clearly and acted upon the solution immediately. Being a technical noob,

sometimes find it difficult to communicate with tech support teams. It was a very different experience with the guys at Online Tech Repairs. You can check out their website www.onlinetechrepairs.com or call them on 1-914-613-3786.
Would definitely recommend this service to anyone who needs help fixing their computers.
Thanks a ton guys. Great Job....!!

Posted by otr214428 at

Add your comment