The Atom Syndication Format is done, cast in stone, will get an RFC number as soon as the appallingly-slow RFC-Editor process concludes. The Atom Publishing Protocol is very close to done; herewith an overview of how it works and what still needs to be settled.
Here’s how the protocol (APP from here on in) works.
You start with a single URI, the URI of the publication.
From that URI, you HTTP-GET a document that tells you about the different collections and blogs and categories and so on in the publication.
You can use the URIs from that document to HTTP-GET lists of the existing entries and media files and categories and so on. Since the lists can be long, you get them in chunks with “previous” and “next” pointers.
To add a picture or movie or audio file to the publication, you pick a collection other than one of the blogs, and HTTP-POST it to that URI in binary form, using a header to suggest a title. Assuming it gets there OK, the server responds with a header telling you what URI got used.
To make a new post, you HTTP-POST it, in Atom format, to the URI of whichever blog you want (most people will probably just have one posting URI for media files and another for their blog). Once again, if it works the server says so and tells you what URI it ended up at.
If you want to update a post, you HTTP-PUT it in Atom format straight to its URI.
If you want to get rid of a post, you HTTP-DELETE it using its URI.
There is no Step 8. That’s all there is to it.
The APP doesn’t say much about security. Since it’s HTTP, there are lots of different excellent security options, and it’s probably not sensible to standardize on what each blogging system will use.
What’s Missing? · That document that you GET in step 2 to start the whole process is called the “introspection document”, and I think that name sucks by the way, but the WG seems to like it. What we’re still arguing about, believe it or not, is exactly which XML tags and attributes to use in the introspection document. The current draft has a few custom tags and attributes, but some don’t like inventing new stuff and others think they’re missing some important capabilities; for example, there’s not an obvious way to support multiple blogs with a nested list of categories for each one. On the other hand, some people are OK with what’s there, maybe with a little tweakage.
Some people would like to invent a new set of XML tags that’s a bit smoother and better-polished than what’s there now.
Some people would like to do introspection using an Atom Feed document; not exactly what it was designed for, but it could be made to work.
Does It Matter? · Speaking as a WG member, I am not convinced that the choice of introspection document format is that important. I think the APP will work pretty well with any of them.
Speaking as WG co-chair, I have to find a way to get the WG to declare consensus on one of these choices; then we are very close to done with the APP. People get remarkably, astoundingly emotional about the design of XML syntax. This is a fact of life. Wish me luck.
