The Atom 0.2 snapshot is out.
- Informal 0.2 spec. Mark Nottingham has agreed to write this up in RFC style.
- Minimal 0.2 feed. Feed title, link, and modified are required. Entry title, link, id, issued, and modified are required.
- Maximal 0.2 feed. Feed tagline, id, generator, and copyright are optional. Entry created, summary, contributor, and content are optional. Feed generator and copyright are new in 0.2. Feed tagline used to be called “subtitle”; entry subtitle has been dropped.
Multipart/alternative 0.2 feed. This is the biggest new feature in this snapshot:
content type="multipart/alternative". It contains 1 or more content elements, of varying types and languages.These are different representations of the same content. Examples: an image, and an HTML representation of the image. Or: an HTML version, and a plain text version of the same content (perhaps run through lynx -dump, or w3m, or simply by stripping all HTML tags).
Publishers should order the alternative content representations in increasing order of fidelity. So if you have an HTML version and a plain text version, put the plain text version first and the HTML version second. If you have an image and an HTML rendition of the content of the image (a longdesc), but the HTML version first and the image second. If you have a translation of the content into another language, put the translation first, and the original content second.
Consumers should render at most one representation of a
content type="multipart/alternative", according to their capabilities and end user preferences. It does not have to be the one the publisher thinks is best, although it should be, if you know how to render content of that MIME type and language and the end user hasn’t specified a preference. The consumer has the final say about what content to render, if any.- 0.2 feed with feed author and 0.2 feed with entry author explain and demonstrate the use cases for the author element. New/changed in 0.2: author is required either on the feed level or on the entry level, and now contains a required name and optional url and email elements. If author exists on the feed but not on an entry, it is assumed to apply to the entry. If author exists on the feed and an entry, the entry author takes precedence. Every entry must have exactly one author, either explicitly included in the entry or inherited from the feed.
- dive into mark Atom 0.2 feed. Live. This uses an additional namespace, Dublin Core, to express entry categories (
dc:subject). This is the only way to express categories in this snapshot. An entry may contain multipledc:subjectelements, although this example does not. - MT template for Atom 0.2.
- dive into mark comments Atom 0.2 feed. Live. This uses
content type="multipart/alternative"to include both an HTML version and a plain-text version of each comment. It also uses entry-level authors, since each entry is a comment by a different author. - MT template for Atom 0.2 comment feed.
- The Feed Validator has been updated to support the Atom 0.2 snapshot. 0.1 feeds will no longer validate. Validator 1.2 source code validates Atom 0.2, and is what is deployed right now. (It still validates RSS. There were no changes to the RSS validation in this release.)
Suggestions that did not make it into this snapshot, but that are still under active discussion:
- Using
xml:baseto handle relative links. But what should it apply to? All URLs (even the<link>element and so forth)? URLs in content only? What about escaped content? Discuss in RelativeLinks. - Allowing HTML in title, tagline, and/or summary, by allowing publishers to declare
type="text/html"andmode="escaped"on those elements (similar to the way they can specify MIME type and encoding on<content>elements now). Blogger did something like this in their experimental 0.1 feed, but it’s not clear they actually need it. (They may need it in the API though.) Regardless, there’s been no discussion on how or if to allow this, so it stays out until we can hash through it.
I was able to get a 0.2 feed working in MovableType in just a few minutes. I grabbed the template and plugins, hit rebuild, and my valid 0.2 feed is here: http://mattcroydon.com/blog/pie-echo-atom.xml
It’s easy as pie.
[edited by moderator to work around stupid MT auto-linking bug]
Comment by Matt Croydon — Tuesday, August 5, 2003 @ 4:18 pm
Did anyone read the article by Paul Festa about Atom/Echo/Pie/Whatever?
http://news.com.com/2009-1032-5059006.html?part=dtx&tag=ntop
Is it just me, or does Festa always seem to be looking for the flames instead of the facts?
Comment by Simon Jessey — Tuesday, August 5, 2003 @ 5:12 pm
Where did tagline come from?? During the SubTitle Discussion and later on the mailing list, it was agreed that feed-level subtitle would be renamed summary (as is also shown on the EchoExample), and that entry-level subtitle would be dropped entirely - leaving summary intat there.
Is there some discussion that I missed that decided to go against both of the prior two discussions?
Comment by GaryF — Tuesday, August 5, 2003 @ 5:29 pm
Damn, forgot you strip html. SubTitle discussion can be found at:
http://www.intertwingly.net/wiki/pie/SubTitle
Extract from mailing list:
“Feed summary works for me. (I’d prefer subtitle, but …)
[SNIP]
Subtitle is gone from entry. I’m OK with that.” - Post by Sam Ruby.
Comment by GaryF — Tuesday, August 5, 2003 @ 5:31 pm
Where did tagline come from? We made it up.
Some history. RSS requires a description for channels. This description (in RSS) is used in a completely different manner than in items.
In my website, the value for this element is “It’s just data”. This isn’t really a description. A subtitle is closer to the mark, but there was a lot of pushback on that. I’m not sure that summary is any better.
Perhaps making it “tagline” and making it optional would be clearer?
Agree? Disagree? Let us know. We can update the wiki in seconds. With all of the pushback surrounding the wiki, it made sense to try an experiment on a small scale to see what people think.
Comment by Sam Ruby — Tuesday, August 5, 2003 @ 6:21 pm
Sam: I brought it up because various people (yourself included) agreed on summary (one of the few topics on the wiki that we’ve reached a clear consensus on). I agree that it should be optional, but see no reason to break the connection between entry level and feed level summary. Why create another element when there is no *need* for it?
Thinking about it “tagline” implies something different to me than summary: a tagline being a (short) phrase associated with an object (association, site etc), and a summary being the substance of an object condensed into something more manageable.
To my eye, summary is the more flexible of the two, and hence more appropriate.
Comment by GaryF — Wednesday, August 6, 2003 @ 8:14 am
Holy shit, that’s a lot of trackbacks.
Tagline would be good, but also summary or description to describe the weblog. Who says you can’t have both?
I urge everyone to go vote at http://www.intertwingly.net/wiki/pie/NameFinalVote - this will be the last name vote, and we don’t want people complaining about the name later. In fact we don’t want to hear anything about the name at all later. ;)
Comment by Jesper — Wednesday, August 6, 2003 @ 9:33 am
If “None of the above” wins, does the vote re-open, or does the 2nd best get the prize?
Comment by SvenByGolly — Wednesday, August 6, 2003 @ 10:23 am
I’ve brought the blojsom atom template into 0.2 goodness :) Read more here, http://www.blojsom.com/blog/blojsom/atom/?permalink=19F5E0ECFBC79F46606612BB2F7664F3.txt
I’ve also made available my atom 0.2 template available.
Comment by David Czarnecki — Wednesday, August 6, 2003 @ 11:31 am
OK, Sean Palmer was kind enough to point out that my initial templates had invalid tag: URIs, since they did not include a date fragment in the tag authority section (that includes the domain name).
http://www.ietf.org/internet-drafts/draft-kindberg-tag-uri-04.txt
This has been fixed in my live template and static examples, and we will make validator test cases to test for my mistake. However, reviewing the syntax requirements of the tag URI RFC more closely, I notice that my MT templates are still inadequate for producing the unique feed id, since it relies on the current year and thus will change on January 1 of each year (which goes against the Atom spec that says the feed ID should never change).
Using the date of the first entry in the system would be sufficient, however I don’t know how to do this in MT. There are probably other solutions I haven’t thought of yet.
Comment by Mark — Wednesday, August 6, 2003 @ 1:21 pm
“Using the date of the first entry in the system would be sufficient, however I don’t know how to do this in MT.”
You could probably use the MTEntry plugin. Of course, as many who who imported their entries from other weblogging systems found out, the first entry of a weblog does not necessarily have the id of 1.
http://mt-plugins.org/archives/entry/entry.php
Comment by Richard — Wednesday, August 6, 2003 @ 7:18 pm
The xml:lang attribute really needs to be required at the <feed> level. Otherwise, the language of the blog title elements and entry titles is undefined. I think the suggestions in the wiki were good - allow subelements to override the parent language attribute, and make ‘unknown’ a valid language attribute to grandfather in content where language metadata is not available.
Comment by Maciej Ceglowski — Wednesday, August 6, 2003 @ 7:50 pm
When I validated my feed at your feed validator (to make sure that I did everything correctly), the link to the “Valid Atom!” image was broken. Do you know where I could grab that, to put it on my site?
Thanks! And keep up the great work with your Atom resources. :)
Comment by milbertus — Wednesday, August 6, 2003 @ 7:51 pm
re dates in tags:
“All dates specify a moment (00:00) of a single day; they MUST NOT be taken as periods of a day or more, such as “the whole of July 2001″ or “the whole of 2000″.”
So you could try extracting the first post and use the date of that, but you’d probably be better off simply handcoding the date the blog was started.
What happens though if you have a blogspot blog which you migrate to a new system/service and hence a new domain name? Should they keep the same tag (ie. maintaining identity), or mint a new tag?
Comment by Eric Scheid — Thursday, August 7, 2003 @ 1:01 am
Eric: see, that’s the thing, the entire point of feed/id is that it is unique and unchanging for all time. So your current domain name isn’t really the best solution (unless you’re willing to continue to use that after you move hosts), but I couldn’t think of a better one. We’ve discussed using real GUIDs (like this: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/213761 , not the “any string will do” [guid] element in RSS) but it’s an implementation burden (especially since we would mandate the same datatype on entry/id, which is required), and if some people can do it and some can only do tag: or urn:, then we have to specify the datatype as xsd:string and that sucks.
Comment by Mark — Thursday, August 7, 2003 @ 10:34 am
I’m stoked about the client-side conneg. There haven’t been many examples of that (AFAIK), and it’d be nice to see good/practical implementations of this.
If it’s really useful, we might see some cross-pollenation back to browsers. :)
Comment by Anonymous — Thursday, August 7, 2003 @ 6:48 pm
I’m stoked about the client-side conneg. There haven’t been many examples of that (AFAIK), and it’d be nice to see good/practical implementations of this.
If it’s really useful, we might see some cross-pollenation back to browsers. :)
Comment by Jeremy Dunck — Thursday, August 7, 2003 @ 6:49 pm