Tim Bray wrote:
I have just finished reading draft-ietf-atompub-protocol-05.txt and
draft-sayre-atompub-protocol-basic-03.txt in some detail.
Just to be clear: I didn't read them "in details".
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.
My personal feelings on those deltas:
+1 on losing workspaces. YAGNI
(http://xp.c2.com/YouArentGonnaNeedIt.html).
Workspaces as containers of collections (and sub-workspaces), having
just a title as metadata, seems to me as being easy to implement and
adding value.
On the other hand, I don't think I'll personally need workspaces…
What's your position on collection nesting?
-1 on losing date/index queries. They're easy to understand,
tractable to implement, and add value.
Agreed, however I'm still uncomfortable with using atom:updated in
date-range queries, I'd introduce an app:modified to be used in "List"
Atom Feeds… (if app:modified is not present, process as if it were
present with the same value as atom:updated; that is, if atom:updated
and app:modified have the same value, you can safely omit app:modified;
this will probably be the case for each and every Generic/Media Resource)
+0 no opinion on custom-XML vs microformat (real opinion: it will make
no difference whatsoever).
I'd say "-X" for microformat, with X being undefined for the moment, for
the same reasons as Eric Scheid [1]. I'd way prefer a "custom-XML" with
a clearly defined media type and using content negotiation to serve
XHTML to web browsers. I'm not opposed to having a microformat defined
in another spec for browser integration…
[1] http://www.imc.org/atom-protocol/mail-archive/msg02004.html
--
Thomas Broyer
