Subject: "atom:entry elements MUST contain an atom:summary element in any of the following cases"

From: Robert Sayre <[email-masked]>
Date: Mon, 14 Feb 2005 18:30:37 -0500

I was looking over some old protocol discussions, and I realized that 
the current Atom entry syntax would be *perfect* for a lightweight 
format to iterate over collections of entries, were it not for the 
requirements around atom:summary.[0]

-----------------------------------------------------------------
atom:entry elements MUST contain an atom:summary element in any of the 
following cases:

* the atom:entry element contains no atom:content element.
* the atom:entry contains an atom:content which has a "src" attribute
   (and is thus empty).
* the atom:entry contains content which is encoded in Base64; i.e. the
   "type" attribute of atom:content is a MIME media type [RFC2045] and
   does not begin with "text/" nor end with "+xml".
-----------------------------------------------------------------

I realize that text was battled over wrt to accessibility, but I have 
some pretty convincing use cases for dropping at least the first one.

Something like this:

<entry>
   <title>...</title>
   <id>...</id>
   <link ... />
   <pub:edit ... />
   <updated ... />
</entry>

would be a really nice way for basic clients to scan entries in the 
editing protocol. Current implementations stuff the whole entry in 
there, but you end up doing a GET on the editURI just to be safe. Also, 
without the summary, linkblogs become more doable.

I'd rather set a higher a bar for specs and include an "Accessibility 
Considerations" section, instead of mandating things like the html "alt" 
attribute does. After all, it takes human judgement to make something 
accessible.

Also, I might be inadvertantly arguing for something similar to the 
@profile proposals, but I hope not ;)

Robert Sayre

[0] 
http://www.atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.3.p.1

---

From: Sam Ruby <[email-masked]>
Date: Mon, 14 Feb 2005 19:52:53 -0500

Robert Sayre wrote:
> Current implementations stuff the whole entry in 
> there

See:

     http://www.imc.org/atom-protocol/mail-archive/msg00442.html

Wouldn't the same objection apply here?

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Mon, 14 Feb 2005 20:06:11 -0500

> Wouldn't the same objection apply here?

That discussion was covering the representation that lives at the end of 
the edit link. This is a little different, because users don't usually 
edit existing entries, and there is no requirement for the full contents 
of the entry to appear in the listing, and you have to GET the entry 
document anyway so you can examine the HTTP headers. The listing 
appearing there is almost always going to be used for "orientation"--a 
way to show the user what they've recently written so they get their 
bearings. The difference between the two approaches is *huge* on, say, a 
GPRS device.

A fuller approach has been discussed for syncing and such, and I can see 
value in including the entire entries in that listing (which would 
mirror getRecentPosts pretty well).

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Mon, 14 Feb 2005 20:18:40 -0500

> mirror getRecentPosts pretty well).

Yes or No: is there an existing XML RPC based weblog API that provides 
this functionallity?

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Mon, 14 Feb 2005 22:59:05 -0500

> Yes or No: is there an existing XML RPC based weblog API that provides 

No, not exactly. But take a look at the LiveJournal API[0], which 
provides a variety of ways to truncate results.

Yes or No: Is asking what capabilities existing XML-RPC protocols 
provide is a productive way to set the limits of the Atom Protocol? [1,2]

Secondly, I provided *two* use cases. What about link blogs?

Robert Sayre

[0] http://www.livejournal.com/doc/server/ljp.csp.xml-rpc.protocol.html
[1] http://blog.kung-foo.tv/archives/001228.php
[2] http://inessential.com/?comments=1&postid=2988

---

From: James M Snell <[email-masked]>
Date: Mon, 14 Feb 2005 20:48:08 -0800

> some pretty convincing use cases for dropping at least the first one.

At the risk of beating the PaceProfile drum to death, I would think that 
  an Accessibility profile could be used to specify specific 
requirements for accessible feeds.  The core could do exactly as you 
suggest below -- not require summary.

<?xml ...
<entry profile="core">
   <title>...</title>
   <id>...</id>
   <link ... />
   <pub:edit ... />
   <updated ... />
</entry>

<?xml ...
<entry profile="core accessibility">
   <title>...</title>
   <id>...</id>
   <summary>...</summary>
   <link ... />
   <pub:edit ... />
   <updated ... />
</entry>

The point is that I think removing the requirement for summary to be 
there when content is not is ok and, in so doing, there are potentially 
viable mechanisms by which the requirement can be tacked on it 
situations where it is Very Useful.

- James M Snell

---

From: James M Snell <[email-masked]>
Date: Mon, 14 Feb 2005 20:54:00 -0800

Robert Sayre wrote:
 > provide is a productive way to set the limits of the Atom Protocol?

<sticking_nose_in>

   Of course not.  I for one don't really give a rip what the existing
   XML-RPC API's currently provide or don't provide.

   Also, I don't see anything in REST that *requires* that full state
   be transferred back and forth between the client and server with
   each request.  That would just be plain silly.  The API calls should
   only ever have to transfer only as much stuff as needed to get the
   job done for any specific task.  What Robert is looking to do is
   perfectly reasonable.

</sticking_nose_in>

- James M Snell

---

From: Walter Underwood <[email-masked]>
Date: Tue, 15 Feb 2005 10:32:12 -0800

I don't think that accessibility is optional. It isn't a profile, it is
a requirement. Maybe summaries are optional, but not because accessibility
is optional.

wunder

--On February 14, 2005 8:48:08 PM -0800 James M Snell <[email-masked]> wrote:

> At the risk of beating the PaceProfile drum to death, I would think that   an Accessibility profile could be used to specify specific requirements for accessible feeds.  The core could do exactly as you suggest below -- not require summary.

--
Walter Underwood
Principal Architect, Verity

---

From: Robert Sayre <[email-masked]>
Date: Tue, 15 Feb 2005 13:41:26 -0500

>   XML-RPC API's currently provide or don't provide.

I certainly care about what they provide, but my proposal was based on 
problems I had with the deployed draft-gregorio-09 protocol.

Sam once told me a story about a group of important open source 
developers having an argument where all sides contended their suggestion 
was "the simplest thing that could possibly work." I see a similar 
problem emerging around the catchphrase "YAGNI" with regard to the protocol.

Here are some observations I've made:

All of the existing XML-RPC APIs provide some sort of querying, yet it's 
been said that avoiding querying would be good. YAGNI? [0]

Client developers have users wondering why blogging clients are so 
completely crippled compared to FTP and Email clients. Rename an image? 
Have a folder full of drafts? etc. YAGNI? [1, 2]

There's been continuous feedback that feed files with link relations 
just aren't good enough. I tend to agree, since we've been unable to say 
anything meaningful about managing feed state. YAGNI? [3]

It's been said that the API should be able to use static files, but none 
of the current protocols allow this. In fact, I don't know of any 
widely-used authoring protocol that does. YAGNI? [4]

Two of our biggest server implementors have asked for super-basic date 
range queries. YAGNI? [5,6]

I was asked to write an entire draft illustrating my thoughts. It's 
certainly not perfect or done, but it's much more capable than any other 
proposals we've had. The only objection I heard was something about web 
architecture, but no actual use case problems. And, truth be told, I 
could live with "URI freedom", since it will cause all sorts of problems 
by crossing hierarchical and security boundaries, and then converge on 
my original suggestion. YAGNI? [7,8]

We've given URIs to all sorts of things that don't have URIs in other 
protocols. YAGNI?

There's no efficent way to incrementally update a collection with the 
current protocol. You see, after any protocol action, the collection 
representation expires, and you have to re-download the whole feed. This 
makes things pretty much intolerable on a cell phone. YAGNI?

So, when I suggest something, I usually try to ensure that it's "the 
simplest thing that could possibly work" and Yes We Do Need It. 
Obviously, I could be wrong, so I'm looking for reasons why I am, or why 
it's not a good tradeoff. I'm not particularly interested in 
catchphrases or religious objections. We could do the whole thing in 
SOAP through one endpoint, and I would be fine with that, if it worked. 
If, the WG decides on a bunch of stuff I think is horrible, I will still 
do my best with the draft.

Robert Sayre

[0] http://www.imc.org/atom-protocol/mail-archive/msg00300.html
[1] http://blog.kung-foo.tv/archives/001228.php
[2] http://inessential.com/?comments=1&postid=2988
[3] http://bitworking.org/news/Proposed_changes_to_draft_gregorio_07#X3
[4] http://www.imc.org/atom-protocol/mail-archive/msg00290.html
[5] http://www.imc.org/atom-protocol/mail-archive/msg00184.html
[6] http://www.imc.org/atom-protocol/mail-archive/msg00200.html
[7] http://www.imc.org/atom-protocol/mail-archive/msg00384.html
[8] http://www.imc.org/atom-protocol/mail-archive/msg00408.html

---

From: James M Snell <[email-masked]>
Date: Tue, 15 Feb 2005 10:39:41 -0800

For feeds intended for human consumption yes, accessibility is a 
requirement.  It should not be assumed that all feeds are intended for 
human consumption.  But, it's not worth debating right now.  +1 on 
making summary optional.

- James M Snell