Tim Bray wrote:
Speaking as an individual WG member, not as co-chair:
I have just finished reading draft-ietf-atompub-protocol-05.txt and
draft-sayre-atompub-protocol-basic-03.txt in some detail.
The ietf..-05 draft is messy and difficult. It has basic concepts
defined multiple times in multiple places, uses a lot of chatty and
informal prose, uses different markup to label the exact same
construct in different documents, and its organization is really
confusing (to me at least).
The sayre..-03 draft is simple, clean, well-written and easy to
understand. It omits two really significant items from the ietf..05
draft: workspaces and the date/index "listing" facility, and does
introspection via the XOXO microformat rather than another XML
vocabulary. It entirely omits the discussion of which parts of an
atom:entry are writeable, which will probably create angst in the
implementer community.
A major omission from both drafts is the pub:control stuff. That's
going to be critical for a lot of stuff.
My personal feelings on those deltas:
+1 on losing workspaces. YAGNI (http://xp.c2.com/
YouArentGonnaNeedIt.html).
Hmm. I wouldn't say that having the ability to discover a group of
related collections all at once is something we aren't going to need.
There are many cases where that may come in quite handy. I would
definitely -1 to the way workspaces are currently defined and to any
notion that we need nested workspaces. I'm particularly partial to this
approach: http://www.intertwingly.net/wiki/pie/PaceSimplifyIntrospection
-1 on losing date/index queries. They're easy to understand,
tractable to implement, and add value.
+1, but the mechanism and description of the mechanism could definitely
be tweaked a bit.
+0 no opinion on custom-XML vs microformat (real opinion: it will
make no difference whatsoever).
True, this could easily turn into a RDF-like permathread thing. Let's
just pick the simplest thing that could possibly work and go with it.
I've been giving lots of speeches in recent weeks, and I do a few
slides on Atom. I describe the APP in one slide, as follows:
===================
1. Start with a single URI, get the “Introspection Document”, find
pointers to Entry and Media collections (HTTP GET).
2. List collections by date/index (GET).
3. Post pictures, podcasts, or other multimedia (POST), get back
their URIs.
4. Create a new entry (POST), get back its URI.
5. Replace an entry (PUT).
6. Remove an entry (DELETE).
It takes me like 60 seconds to talk through this, the audiences nod
and look thoughtful and I can practically hear them thinking "yeah, I
could implement that".
I am lie-down-in-the-road -1 on anything going into the protocol
which would make this description wrong.
I have a bunch of detailed editorial comments, particularly on ietf..
05, but on reflection I'll send them to the editors. -Tim
