Subject: atom:summary or atom:content required?

From: Norman Walsh <[email-masked]>
Date: Sun, 11 Jul 2004 10:40:20 -0400

Is an entry required to have at least one of atom:summary or
atom:content?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Unless one is a genius, it is best to
http://nwalsh.com/            | aim at being intelligible.--Anthony Hope

---

From: Mark Pilgrim <[email-masked]>
Date: Sun, 11 Jul 2004 11:28:36 -0400

> Is an entry required to have at least one of atom:summary or

Not currently.

-- 
Cheers,
-Mark

---

From: Tim Bray <[email-masked]>
Date: Sun, 11 Jul 2004 09:19:07 -0700

>> Is an entry required to have at least one of atom:summary or

Should it be? -Tim

---

From: Sam Ruby <[email-masked]>
Date: Sun, 11 Jul 2004 12:58:08 -0400

>>> Is an entry required to have at least one of atom:summary or

For a historical perspective, neither RSS 1.0 nor RSS 2.0 require 
titles. (*)

If you do a current search on «"title only" feed», you will find that 
such feeds are(1) still being produced, and (2) widely disliked by 
consumers.

- Sam Ruby

(*) More history:
   - In 0.91, title is required, description is optional
   - In 0.92, neither title nor description is required.
   - In 2.0, at least one of title or description is required.

---

From: Graham <[email-masked]>
Date: Sun, 11 Jul 2004 13:18:35 -0400

>   - In 2.0, at least one of title or description is required.

2.0 has it right. Not all content systems include a title field, only a 
body, so requiring titles requires synthetic titles, which are 
impossible to display in a non-sucky way, since they're always the 
wrong length. Therefore one of the 3 should be required.

(I've said this before and got booed by the XSLT crowd)

Graham

---

From: "Roger B." <[email-masked]>
Date: Sun, 11 Jul 2004 12:33:48 -0500

> If you do a current search on <"title only" feed>, you will find that

Sam: I'm a producer of a whole batch of feeds like that. The Macromedia
support and Fusebox methodology forums don't currently produce native feeds,
so I've got a scraper set up that pulls down thread titles/links and dumps
'em into RSS.

People who use them would certainly _prefer_ content in those feeds, but
when the alternative is no feed at all, folks get real appreciative, real
fast. So dislike is a relative thing, IMX. 

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/

---

From: Sam Ruby <[email-masked]>
Date: Sun, 11 Jul 2004 13:54:12 -0400

Graham wrote:

> so requiring titles requires synthetic titles

 From the Atom Protocol description of titles in POSTs [1]:

     MUST be present. The element may be empty, to explicitly indicate
     "no title". Servers SHOULD NOT try to generate a title if one is not
     provided. The type attribute MAY be present, and if not it defaults
     to "text/plain". If present, it MUST represent a MIME type that the
     server supports.

- Sam Ruby

[1]<http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-00.html#rfc.section.3.5.3>

---

From: Graham <[email-masked]>
Date: Sun, 11 Jul 2004 14:11:35 -0400

>     to "text/plain". If present, it MUST represent a MIME type that the

Firstly: What?!? How is an empty element a more explicit way of saying 
there isn't one than omitting it completely? This is nonsense.

Secondly, I was referring to the format spec:

   atom:entry elements MUST have exactly one "atom:title" element.

How does that square with the protocol spec?

Graham

---

From: Sam Ruby <[email-masked]>
Date: Sun, 11 Jul 2004 14:27:20 -0400

> fast. So dislike is a relative thing, IMX. 

Thank you for coming forward.  I was looking for such an example.

Note that there are slippery slope arguments on both sides of this.  If 
you have a format where everything is optional and everything is 
extensible, then interoperability and user experience suffers.

If, on the other hand, you require so much that only a few tools can 
produce valid contents, then either people start ignoring the validity 
constraints or stop producing the content.  Either way, something 
important suffers.

My personal leanings for Atom are towards being more restrictive and 
predictable, particularly as there clearly are viable alternatives which 
are less restrictive and predictable.

Roger, as somebody who has been following Atom since before it was 
called Echo, and as a producer of feeds for which there are neither a 
summary or a content (and therefore, a recipient of complaints), do you 
think it is important for Atom to support feeds which have neither?

- Sam Ruby

---

From: Sam Ruby <[email-masked]>
Date: Sun, 11 Jul 2004 14:46:33 -0400

> there isn't one than omitting it completely? This is nonsense.

Counter-example: I can point to RSS feeds where the absense of a <link> 
element merely means that the permalink is to be found elsewhere.

My preference for Atom is that both the format and protocol discourage 
the synthetic generation of titles and have a clear an unambiguous way 
of expressing that no title was provided.

> How does that square with the protocol spec?

The protocol spec clearly provides more guidance and informative at the 
moment.  However this is resolved, the protocol and format specs should 
be made more consistent.

- Sam Ruby

---

From: "Roger B." <[email-masked]>
Date: Sun, 11 Jul 2004 20:07:25 -0500

> Note that there are slippery slope arguments on both sides of this.  

Sam: Agreed. I just wanted to point out a practical example of a feed that
_can't_ have content, and one that many people in the relevant community
depend upon.  

It's funny... I produce thousands of individual feeds, but of them all, that
relative handful of crippled, scraped snippets have generated more "thank
you"s and ongoing good vibes than all the rest combined. 

> think it is important for Atom to support feeds which have neither?

For my purposes? No. My no-content feeds are distributing such limited info
that there's really no need for anything more than RSS. Trying to force that
kind of thing to work with Atom nets the user nothing (the RSS and Atom
versions would be effectively identical), and blunts Atom's purpose (clearer
specification) in the process. 

And if I'm absolutely determined to use Atom anyway, what's stopping me from
just inserting an empty atom:content or atom:summary element? It might be
tacky, but it's also an edge-case... I'm sure most aggregators would
compensate by doing what they're already doing with description-less RSS.