Moving from Atom 0.3 to 1.0
Thursday, 21 July 2005
Now that the Atom 1.0 specification is pretty much final and waiting for approval we are going to see a lot of people moving from Atom 0.3 to Atom 1.0. Many people will automatically move to Atom 1.0 when they upgrade their weblog software, or when large weblog providers such as Blogger update their software. The rest of us, who are going to change our feeds manually are going to run into a number of differences between Atom 0.3 and Atom 1.0.
Below I will highlight some of the main changes. This is a guideline to help you update your feed and make it validate. This is by no means a complete description of Atom 1.0. It does not contain a complete list of all changes and all new elements. If you want to know every little detail about the Atom 1.0 standard you need to read the specification itself.
The feed element
In version 0.3, the feed element used to define the version number and the XML namespace. In the new Atom 1.0 specification the feed element still exists, but there are a couple of changes.
One of the first things you will notice is that Atom 1.0 uses a new XML namespace. The version 0.3 namespace used to be http://purl.org/atom/ns#, which you are going to have to change to http://www.w3.org/2005/Atom.
The next change is that the version attribute is dropped. This attribute used to indicate which version of the Atom specification was used. From now on this will be handled by the namespace, I believe. If you want your feed to validate properly you are going to have to delete this attribute.
The id element
There are not many changes to the id element, except that it is now required for both the main feed element, as for all the entry elements. So, if your feed does not already use an id for both these elements, you must add them now. If you want more information about generating proper ids for your Atom feed, read the article How to make a good ID in Atom by Mark Pilgrim.
The author element
Your feed element must contain an author element, unless all entry elements contain an author element. This has not changed, but it is now allowed to use more than one author element. For example, if you wrote an article together with another person, you could add two author elements. One for yourself and one for the other author.
The tagline subtitle element
The Atom 0.3 specification defined a tagline element which was used to convey a human-readable description for the feed. This element was renamed to subtitle in the Atom 1.0 specification.
The copyright rights element
The Atom 0.3 copyright element is also renamed in the Atom 1.0 spec. The new element is called rights. One other change is that the rights element is now also allowed in entry elements, while previously it was restricted to the feed element.
The generator element
The url attribute of this element was renamed to uri. If your feed contains a generator element, you must also rename the url attribute to uri, otherwise the feed will not validate.
The info element
The info element is completely removed from the Atom 1.0 spec and has not been replaced with another element. If you use info elements in your old Atom 0.3 feed, you should remove them.
The modified updated element
The modified element was renamed to updated in the Atom 1.0 spec. The updated element is still required for the feed element and each entry element, but the date no longer has to be in the UTC timezone. One major change is also that the updated element no longer needs to be changed for each modification. You can decide for yourself which modification warrants a change to the updated element.
The issued published element
The issued element was also renamed. This element is now called published and is no longer required for each entry element.
The created element
This element is the second that has been dropped from the Atom 1.0 specification and if your feed uses this element you need to remove it.
The link element
There are a number of changes to the link element, but mostly they are additions, such as the hreflang and length attribute.
One change is that the value of rel, the relationship of the link to the feed or entry, is no longer defined by the Atom API specification, instead they should be registered with the IANA. The Atom 1.0 specification does define five initial relationships of which the first already existed: alternate, related, self, enclosure and via. The rel attribute is also not required anymore, just like the type attribute.
In case of the feed element there are two changes: a link with the relationship of alternative is no longer required. Instead it is highly recommended to add a link with the relationship self, which points to the IRI where this feed can be retrieved.
The category element
Until recently it was not possible to defined categories or tags in Atom. Some people created a workaround for this by importing the Dublin Core namespace and using its subject element. This is no longer needed, because as of version 1.0 Atom now includes the category element.
The category element can occur multiple times within a feed or entry elements. The precise contents of the term, scheme and label attributes are not defined and could look like this:
<entry> <title>Moving from Atom 0.3 to 1.0</title> <link rel='alternate' src='http://www.rakaz.nl/nucleus/item/103' /> <category term='atom' scheme='http://www.rakaz.nl/nucleus/tags' /> <category term='feed' scheme='http://www.rakaz.nl/nucleus/tags' /> <category term='standards' scheme='http://www.rakaz.nl/nucleus/tags' /> ...
Person constructs: the name, url uri and email elements
In an effort to rename all occurrences of URL to URI, the url element was also renamed. The new uri element functions in exactly the same way as the url element used to do, so the only thing you will have to do is rename all url elements.
Text contructs: the title, tagline subtitle, summary and content elements
One of the big changes between Atom 0.3 and Atom 1.0 is the way text constructs are defined, starting with the name. Text constructs were initially called Content constructs.
Atom 1.0 defines that text constructs have a type attribute which can be one of the following values: text, html, xhtml. In addition to that, the content element can also contain a MIME media type as the value of the type attribute. The mode attribute has been removed by the Atom 1.0 specification.
| Version 0.3 | Version 1.0 | |
|---|---|---|
type |
mode |
type |
| text/plain | escaped | text |
| text/html | escaped | html |
| application/xhtml+xml | xml | xhtml |
| application/xml | xml | application/xml |
| application/mathml+xml | xml | application/mathml+xml |
| image/svg+xml | xml | image/svg+xml |
| image/png | base64 | image/png |
| application/pdf | base64 | application/pdf |
In the table above you can see how the new values of type map to the old type / mode combinations. If your feed uses a different combination of type and mode, you may need to read the new specification carefully to determine how you must change the content of your feed.
The value text is used by default if the type attribute is not defined in the text contruct.
Conclusion
It is not easy to determine how much work it will take to convert your Atom 0.3 feed to Atom 1.0. It depends on which features your feed uses, but it most cases it will require only relatively few changes. Atom 1.0 is not a completely new standard, and despite that it is not compatible with Atom 0.3 in many ways, you can clearly see that the new standard is a descendant of the work done by Mark Nottingham and many others on the Atom wiki little more than a year and a half ago.
Thanks very much for this! A few minor comments/corrections:
atom:published is not required. atom:link rel and type attributes are also now optional.
icon, logo, and source are new.
This is a great resource for anyone looking to upgrade their feed but do not want to sift through the (very dry) Atom 1.0 Draft.
Now I need someone to get to the SharpReader team and tell them to upgrade their software to support ATOM 1.0, because atm I already have two unreadable feeds and I suspect this number to continually grow…
If I’m not mistaken, the contributor element suffices the need for multiple author elements.
Jonas, there is a subtle difference between contributors and authors and both situations can happen. You can have a story with two authors, but also a story with one author and a contributor.
It’s about the relationship between the two. If they two worked together and wrote the story as a team they both entitled to being called author. If one would be called author and the other one a contributor, this would basically tell the world that one author is more important than the other.
> Now I need someone to get to the SharpReader team and tell them to upgrade their software to support ATOM 1.0
Someone on the team (of one) is already working on it ;-)
Using the feed for this blog (http://www.rakaz.nl/nucleus…), I found that it’s currently not well-formed xml as an internal table in this very entry (oh the irony… ;-) has a tbody tag that is not closed…
That’s the downside of embedding (non-encoded) xhtml in your feed – you had better be damn sure it’s valid xml or you’ve just screwed your entire feed…
It looks like the feed is fixed:
http://feedvalidator.org/ch…
/me hides in shame.
Sounds like the kind of thing that can easily be avoided/fixed by running the content through Tidy.NET before running the Atom/RSS x.x build process.
After a few minutes of coding, I’ve finished my Atom generator. Because I’m a frequent visitor of Anne van Kesteren’s weblog, I came across a novelty in the world of web development standards: Atom 1.0.
That’s why I decided to introduce the Atom 1.0 feed for the content of GeekBlog.nl.
Is there a good way to generate a feed containing, for instance, blog entries and their associated comments, so that the relationships are clear?
Well, the work never stops, does it? :) Anyway, thanks a lot for this excellent outline of the new specification.
Love your trippy design work here also
Encouraged by Neil’s decision to update his Atom 0.3 feeds to Atom 1.0 – although still a draft format – I too did so tonight. After quickly comparing the draft memo with Neil’s feed and my old atom-script I managed to get it to validate on the second …
I didn’t find a better way to contact you so I’m posting this here although I realize it’s off topic: Your blog has one of the most slick designs I’ve ever seen on the net so far. If you did it yourself, you should be really really proud.
It seems to me that, in the final Atom draft, the ‘feed’ element doesn’t have an ‘id’ attribute. Beyond that minor error, this was very helpful in updating my feed for 1.0.
Nice overview. Thanks a lot!
By my read, today is August 46th or thereabouts, which I guess qualifies as early August, so I’ve gone ahead and made the Feed Validator issue deprecation warnings whenever it encounters Atom 0.3 feeds ( example). No other code changes were mad
I really don’t think the namespace will change in future versions, depsite the lack of a version attribute. The current design of Atom 1.0 is to allow backwards compatible evolution in which new elements are ignored by older clients, without requiring each client to update itself immediately for every spec change.
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
If anyone ever figured out how to get Blogger to feed properly, I’d love to know how they did it…
I’ve written XSL stylesheets that allow conversion of Atom 0.3 to Atom 1.0 and then Atom 1.0 to RSS 2.0:
http://atom.geeekhood.net/
ATOM と RSS の 各要
Atom 0.3 と 1.0 の相異点: Atom 0.3 と 1.0 の相異点を見やすく示したサイトがなかったので，まと めておくことにしました．下が対応表になります (XPath で書いてありま す)．空白は，対応する要
rakaz – Moving from Atom 0.3 to 1.0: rakaz – Moving from Atom 0.3 to 1.0 Blogged with Flock