Subject: Last Call: required summary or content?

From: Robert Sayre <[email-masked]>
Date: Mon, 25 Apr 2005 12:48:46 -0400

Greetings ATOMPUB and IESG, here is a last call issue, questioning the 
requirement for there to be a summary or content element in the Atom 
Format. Note that not all of the points are subjective musings on the 
nature of 'content' or 'consensus'. Some of them concern specifications 
which normatively reference the Atom Format, and one of them questions 
whether we've made proper use of one of our normative references.

Process
---------------------------------
It has been repeatedly suggested that it would be somehow inappropriate 
for me to raise this issue during last call. This is incorrect.

"After it is submitted to the IESG, the IESG announces an IETF-wide last 
call. This helps get the attention of people who weren't following the 
progress of the draft, and can sometimes cause further changes to the 
draft. It is also a time when people in the WG who feel that they 
weren't heard can make their comments to everyone."

-- http://www.ietf.org/tao.html

Limiting Use
---------------------------------
Atom protocol, del.icio.us, daypop, craigslist, and HTTPLR.

Why do we wish to make these illegal under the Atom format? It servers 
no interop purpose. There is only advocacy along the lines of "users 
like feeds with content or summaries". Well, so what?

Do daypop users like full content feeds? Do users on cellphones like 
them? Do apps have problems when feeds are not full content? The answer 
to all of these questions is no. Are they use cases that fall outside of 
our charter? No. We syndicate 'headlines'.

RFC2119
---------------------------------
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they *MUST only be used where it is
actually required for interoperation* or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.

Atom Protocol
---------------------------------
We have no idea how these requirements will effect the Atom Protocol, 
since we haven't settled on the meaning of empty vs. missing elements.

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

The cost of requiring summary or content is unknown, and therefore 
constitutes an unacceptable risk for the protocol.

The Format/Protocol Overlap
---------------------------------
http://www.mnot.net/blog/2005/04/12/feed_state

Requirements in the Atom Format have made the protocol move to a 
separate syntax for "collections". If you read mnot's article above, 
you'll see that his problem overlaps a great deal with collection 
traversal in the protocol. By leveraging the same syntax for both 
problems, users can ease into the protocol by using simple things like 
mnot's proposed link relations. It would be simple to fit that into this 
protocol:

http://www.ietf.org/internet-drafts/draft-sayre-atompub-protocol-basic-00.txt

If we can't use the format for own protocol, what does that say about 
the level of reuse this restriction allows?

Prior Art
---------------------------------
RFC 2822:                                Optional body
RSS 0.90: Required title, Required link, No       description
RSS 0.91: Required title, Required link, Optional description
RSS 0.92: Optional title, Optional link, Optional description
RSS 1.0:  Required title, Required link, Optional description
RSS 2.0:  Optional title, Optional link, Optional description
Atom 0.3: Required title, Required link, Optional summary and content

Explicit Indication
---------------------------------

     http://www.imc.org/atom-syntax/mail-archive/msg06598.html

     From the Atom Protocol description of titles in POSTs:

     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.

This makes sense. It does not, however, make sense for many 
metadata-only applications to explicitly indicate there is no summary or 
content. One example would be a titles-only listing of a large set of 
entries.

Consensus, or not
---------------------------------

* http://www.imc.org/atom-syntax/mail-archive/msg14154.html
* http://www.imc.org/atom-syntax/mail-archive/msg14152.html
* http://www.imc.org/atom-syntax/mail-archive/msg14162.html
* http://www.imc.org/atom-syntax/mail-archive/msg10362.html
* http://www.imc.org/atom-syntax/mail-archive/msg06601.html
* http://www.imc.org/atom-syntax/mail-archive/msg13589.html
* http://www.imc.org/atom-syntax/mail-archive/msg10387.html
* http://www.imc.org/atom-syntax/mail-archive/msg10340.html
* http://www.imc.org/atom-syntax/mail-archive/msg10310.html

...and the consensus call:
* http://www.imc.org/atom-syntax/mail-archive/msg10338.html

following that, the chairs got pushback on the summary requirement. I 
didn't see any text for or against the requirement previous to that.
Then, accessibility arguments from Pilgrim and Isofarro, but do they 
still stand? I asked the chairs to have the current requirements 
reviewed by an accessibility expert.

Besides, this is not the US Congress, where various riders slide through 
on the back of other legislation. Tying this requirement to the removal 
the abysmal content model that preceded it, and then insisting on 
'consensus' around this requirement doesn't make much sense to me.

Accessibility
---------------------------------
No one is still making this argument, right?

Robert Sayre

---

From: Graham <[email-masked]>
Date: Mon, 25 Apr 2005 19:01:58 +0100

Can you post some links to examples of feeds you think are difficult to 
express in the current syntax? That would be considerably more 
constructive than whatever the hell that was.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Mon, 25 Apr 2005 14:10:16 -0400

> constructive than whatever the hell that was.

I've done that before. Go read the archives.

---

From: Tim Bray <[email-masked]>
Date: Mon, 25 Apr 2005 11:25:57 -0700

On Apr 25, 2005, at 11:01 AM, Graham wrote:

> Can you post some links to examples of feeds you think are difficult 
> to express in the current syntax? That would be considerably more 

What Rob wants is what he said in 
http://www.imc.org/atom-syntax/mail-archive/msg14157.html

I decided it would help if there was an actual Pace: 
http://www.intertwingly.net/wiki/pie/PaceOptionalSummary

---

From: Julian Reschke <[email-masked]>
Date: Mon, 25 Apr 2005 21:02:08 +0200

> http://www.intertwingly.net/wiki/pie/PaceOptionalSummary

Thanks.

Here's a meta comment, based on several years of real world 
implementation experience with the IETF WebDAV specs:

It doesn't make sense to REQUIRE protocol elements for which there are 
valid reasonable use cases where implementations can't supply them and 
which aren't absolutely needed for interoperability. Also, if a protocol 
element is indeed not absolutely required, make sure that it's clear 
that leaving it out is *better* than supplying bad data.

I'll supply two examples:

#1: DAV:displayname property

Many readers of RFC2518 came to the conclusion that a WebDAV resource 
MUST have a DAV:displayname property. Many implementations that aren't 
able to provide any additional metadata besides what they get from the 
file system thus use the filename (minus path) instead. This is not only 
a complete waste of bandwidth, but also causes lots of interop problems 
when resources like these are copied to other servers where 
DAV:displayname indeed works as designed (for instance, renaming the 
resource will not cause DAV:displayname to change anymore like it did on 
the origin server).

#2: DAV:getcontentlanguage property (same for HTTP "Content-Language" 
header)

I've seen servers providing the server installation's locale name as a 
default. I've seen clients (MS Webfolder) that send a Content-Language 
header hardwired to "en-us" for any document they HTTP PUT. In both 
cases, recipients receive bad metadata, instead of no data at all which 
would be preferrable.

In both cases, there'd be fewer interop problems (and incorrect 
metadata) if the specs would allow not to send these protocol elements 
(and be clear about that you shouldn't make them up if you don't have 
them).

Please consider this when discussing this Pace and the link/alternate 
issue as well.

Best regards, Julian

---

From: Graham <[email-masked]>
Date: Mon, 25 Apr 2005 21:24:47 +0100

I would much prefer changing the MUST to a SHOULD rather than dropping 
the requirement completely, which would achieve the same goal. I don't 
believe requiring at least a summary is an unfair baseline requirement 
in other use cases.

(btw I also think there's an equally valid use-case for body-only feeds)

Graham

On 25 Apr 2005, at 7:25 pm, Tim Bray wrote:

>> re constructive than whatever the hell that was.
>

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Apr 2005 16:34:07 -0400

Hi.  Speaking as an IESG member with limited context on the issue you
raise, you did not provide enough detail for me to understand the
point you bring up.

I think the focus of your message was wrong.  You spent a lot of space
talking about IETF process and about how this would effect various
uses of atom.

Your understanding of the process does seem correct, but it seems like
it is the wrong focus for the argument you are trying to make.  Rather
than explaining why it is appropriate for you to make your argument
please get around to making the argument whatever it is.  In particular, focus on the following:

* What the specification does currently
* What you would like it to do instead
* why you believe this is the right choice

In addition it would be helpful if you would explain other positions
to the best of your ability.  In all likelihood advocates of those
positions will fill us in in great detail, but it can't hurt for you
to povide your understanding of the complete thinking on the issue.

---

From: Sam Ruby <[email-masked]>
Date: Mon, 25 Apr 2005 16:32:54 -0400

> http://www.intertwingly.net/wiki/pie/PaceOptionalSummary

   -1

Steamroll over me and others if you must, but I believe that title only 
feeds are more often that way due to an error of omission than by an 
explicit design choice.  Enough so that it warrants someone explicitly 
saying "this summarly intentionally left blank", thus:

   <summary/>

Given a way to express an intentional omission of a summary, this 
discussion changes from a discussion of use cases that allegedly are not 
supported, to one of whether tools like RNG grammars and feedvalidators 
can assist people who produce feeds in making their intents clear.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Mon, 25 Apr 2005 16:46:28 -0400

On 4/25/05, Graham <[email-masked]> wrote:
> the requirement completely, which would achieve the same goal. 

Incorrect. There are no interoperability issues with title-only feeds.
There may be users unhappy with the content in some cases, but that's
not a technical issue.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Mon, 25 Apr 2005 18:14:30 -0400

> raise, you did not provide enough detail for me to understand the

Hi Sam. I apologize for that. I see now that I was too brief on the 
technical point, and too long winded for the IESG. The process stuff was 
for the benefit of the WG, most of whom (including me) are new to the IETF.

> it is the wrong focus for the argument you are trying to make. 

Perhaps I misunderstood the process a bit, in that I thought I had to 
send my message to the IESG as part of the process. I consider it quite 
likely that the WG will resolve this issue itself, but I wanted to make 
sure it was not stuffed by process arguments.

> * What the specification does currently

In an Atom Entry, the specification currently requires a minimum set of 
elements: <title>, <id>, and <updated>. Typically, there will also be a 
<link> element. The specification includes a provision that allows its 
omission on the condition that there is a <content> element. In addition 
to that, the specification requires that either <summary> or <content> 
be present.

> * What you would like it to do instead

I want to allow the metadata-only feeds allowed by all flavors of RSS, 
and the omission of the <content> and <summary>. Such feeds are commonly 
termed "title-only feeds", because that is all that is visible to the 
user (the title is usually hyperlinked w/ the link element).

> * why you believe this is the right choice

I believe this is the right choice because title-only feeds are not a 
significant source of interoperability problems in current formats. It 
can often be a source a unhappy users, but that is not a specification 
problem. There are services taking this approach that are successful.

In addition, the WG has not decided on the significance of absent or 
empty summary/content in the Atom Protocol.

> to povide your understanding of the complete thinking on the issue.

The other position seems to be that title-only feeds are usually the 
result of an error made by a producer who doesn't understand syndication 
users' expectations very well. I fully agree that's a common occurrence, 
but it results in unhappy users who complain to the publisher, not 
broken or buggy clients. On the other end of the spectrum, advanced, 
site-to-site, or bandwidth-constrained users frequently produce 
title-only feeds.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Mon, 25 Apr 2005 18:22:40 -0400

> which aren't absolutely needed for interoperability. 

This Pace addresses my concerns in full.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Mon, 25 Apr 2005 20:05:37 -0400

> user (the title is usually hyperlinked w/ the link element).

I will again point out that the current format allows for empty summary 
and/or content elements.

I have seen errors that the requirement for the inclusion of such 
elements would have prevented.

I have seen no arguments as to why placing such empty elements would 
impose an unreasonable burden on implementers.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Mon, 25 Apr 2005 20:17:12 -0400

[snipped IESG]

> I will again point out that the current format allows for empty summary 

Sure, but it doesn't define them.

> elements would have prevented.

Please define the term error more precisely.

> impose an unreasonable burden on implementers.

Please outline the effects of this requirement on the protocol, because 
I have no idea what they might be.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Tue, 26 Apr 2005 11:17:28 +1000

> http://www.intertwingly.net/wiki/pie/PaceOptionalSummary

+1

---

From: Antone Roundy <[email-masked]>
Date: Mon, 25 Apr 2005 20:20:23 -0600

+1

---

From: "James Tauber" <[email-masked]>
Date: Tue, 26 Apr 2005 10:31:50 +0800

+1

James
-- 
  James Tauber               http://jtauber.com/
  journeyman of some    http://jtauber.com/blog/

---

From: Martin Duerst <[email-masked]>
Date: Tue, 26 Apr 2005 10:38:42 +0900

+1

---

From: Tim Bray <[email-masked]>
Date: Mon, 25 Apr 2005 22:23:15 -0700

I was driving to the airport with Lauren, whom some of you will know, 
she's technical but hasn't been following Atom.  I explained the debate 
we are having over the required-ness of <atom:summary>, and she said 
"Don't you have anything better to talk about?"  I suspect she has a 
point.  Suppose we leave it the way it is... people who don't want to 
include a summary can use <summary/>, so it's just silly to say that 
there's an example of a current feed that would be ruled out.  For that 
matter, Graham's body-only feeds can be done with <title/>.  I can see 
Sam's arguments, but on the other hand, the errors that might get 
caught by requiring summary are probably boring corner-cases anyhow.

Which is to say, it doesn't matter very much.

Which is to say, Paul & I are gonna watch a little more debate and then 
we'll call rough consensus one way or the other, at which point I at 
least will become crushingly rude to anyone who wants to invest more 
time in this.  -Tim

---

From: Julian Reschke <[email-masked]>
Date: Tue, 26 Apr 2005 09:14:50 +0200

Sam Ruby wrote:
> ...
> ...

Again speaking based on experience using XML formatted protocol data:

As far as I can tell, using empty elements to signal the *absence* of 
information is a potential source of interoperability problems. For 
instance, clients may behave differently based on whether some piece of 
data exists, but fail to handle an empty string value as "no" value.

So, at a minimum, the spec would need to be clear about the fact that if 
something has no text content, it means "this information is missing" 
instead of "this information is present and has an empty string value".

Also keep in mind that people *will* break rules as long at it 
simplifies their own work and they get away with it. It'll be hard to 
explain why it's necessary to marshall an element with no text content, 
if clients will treat the absence of this element the same way (and they 
will). If both notations carry the same semantics, and both are likely 
to be used no matter what the RFC says, it IMHO would be wise to allow both.

Best regards,

Julian

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 26 Apr 2005 09:36:47 +0100

> http://www.intertwingly.net/wiki/pie/PaceOptionalSummary

0

As editor of the one the protocols cited in favour (HTTPLR) I'd like to 
clarify this position, especially as the debate around this issue has 
imo been emotionally charged; most recently there's been talk of 
inappropriateness and steamrolling. That encourages me to stay neutral.

The absence or otherwise of atom:summary causes no interoperability 
problems for that protocol; HTTPLR agents are not licensed to process 
summaries. The use of Atom in HTTPLR is arguably not a common usecase 
(today at least). Of the people I know implementing it, atom:summary has 
not come up as an issue. It appears to make no odds one way or another 
if atom:summary there or not empty or not.

Finally please note that HTTPLR is different from the other cases cited 
which might or might not be relevant to the IESG and ATOMPUB. First, 
it's a protocol, not a website. Second, it's not gone through the IETF 
process a la APP, though it will appear as an I-D around June of this year.

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Tue, 26 Apr 2005 07:14:35 -0400

On 4/26/05, Tim Bray <[email-masked]> wrote:

> she said
> point.  

Welcome to atom-syntax.  :)

> Suppose we leave it the way it is... people who don't want to
> there's an example of a current feed that would be ruled out. 

Consider a message from client to server using the Atom Protocol.
Do the following messages mean the same thing?

<entry>...
  <id>...</id>
  <title>...</title>
  <content/>
</entry>

<entry>...
  <id>...</id>
  <title>...</title>
  <summary/>
</entry>

<entry>...
  <id>...</id>
  <title>...</title>
  <content/>
  <summary/>
</entry>

I have my thoughts, but the WG hasn't decided.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Tue, 26 Apr 2005 09:19:03 -0400

Tim Bray wrote:
> Sam's arguments, but on the other hand, the errors that might get caught 
> by requiring summary are probably boring corner-cases anyhow.
> 

The feedvalidator catches silly, boring corner-cases every day.

I hesitate to bring it up again as it has proven to incite adhominen 
attacks from within this workgroup, but we have an example of a 
respected journalist who has published a book in which he specifically 
called out this.

And we have the experience from RSS 2.0 (motto: everything is optional! 
and extensible!) whereby Don Box introduced xhtml:body into his feed in 
place of description, something that most aggregators support today.

On the other hand, what we have is arguments that entries with empty 
summaries is not possible with the current format - something that is 
blatantly incorrect.

We also had a very complex and delicate negotiation a while back that 
seems to have been forgotten.  It is quite possible to produce feeds 
with content that is base64 encoded binary or out of band.  What is 
desired in such circumstances is precisely akin to specifications that 
require alt attributes for img tags.  It atom's case, it is a summary.

If you want to push through this pace, I suggest that we revisit and 
reopen those discussions.  Schedule be damned.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Tue, 26 Apr 2005 09:44:56 -0400

> respected journalist who has published a book in which he specifically

So? What does that have to do with interop?

> place of description, something that most aggregators support today.

Yes, and he just might stick xaml:body in there next year. We can't stop him.

> summaries is not possible with the current format - something that is

Well, the argument was originally that people don't like title-only
feeds, so we shouldn't even worry about them (see journalist point
above).

> require alt attributes for img tags.  It atom's case, it is a summary.

I've edited Tim's Pace to show what the resulting text would look
like, since a summary would still be required in such circumstances.
Hopefully, the resulting requirements are clear now.

Robert Sayre

---

From: "James Tauber" <[email-masked]>
Date: Tue, 26 Apr 2005 23:31:12 +0800

Does much of this debate come down simply to whether there is a
distinction between an empty summary and an absence of a summary?

I am in favour of an optional summary because if there is no summary, I
would rather not see <summary/>

I can understand that people that don't have a problem with <summary/>
meaning "no summary" would not see any reason to make it optional.

James

---

From: "Roger B." <[email-masked]>
Date: Tue, 26 Apr 2005 14:33:38 -0500

I'd be willing give a +1 to SHOULD language regarding summary/content.
I'd prefer one or the other be required for a weblog-centric format
like Atom, but I'll just do what I already do with title-only RSS
feeds... have my code reject them as inadequate.

--
Roger Benningfield

---

From: "Roger B." <[email-masked]>
Date: Tue, 26 Apr 2005 14:35:19 -0500

> Do the following messages mean the same thing?

Robert: In my app? Yep, exactly the same.

--
Roger Benningfield

---

From: Robert Sayre <[email-masked]>
Date: Tue, 26 Apr 2005 15:54:53 -0400

> I'd be willing give a +1 to SHOULD language regarding summary/content.

That's not good enough. You have to demonstrate an interop problem to
say SHOULD or MUST.

> feeds... have my code reject them as inadequate.

Just like it would reject an entry containing <summary/>, since it
means the same thing, right?

You yourself send them:
http://www.imc.org/atom-syntax/mail-archive/msg14147.html

They are clearly adequate for some class of applications, so please
demonstrate the interoperability problems they cause.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Tue, 26 Apr 2005 21:49:22 +0100

> That's not good enough. You have to demonstrate an interop problem to

So your app sends me an Atom document that looks like this:

<entry>
<id>whetever</id>
<title>So Caleb is Lindsey's father</title>
</entry>

What does this mean?

a) A title only feed
b) A full entry with the summary missing.

Without knowing this (which it wouldn't under Tim's proposal), my app 
can't reliably interoperate with yours.

(Why does my app need to know? None of our business)

Graham

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 26 Apr 2005 23:09:33 +0200

> <title>So Caleb is Lindsey's father</title>

That’s invalid, since it’s missing both an atom:content as well
as an atom:link[@rel='alternate']. It must have one or the other.

> Without knowing this (which it wouldn't under Tim's proposal),
> my app can't reliably interoperate with yours.

How would supplying a token <summary/> change anything about the
meaning?

Regards,
-- 
Aristotle

---

From: Antone Roundy <[email-masked]>
Date: Tue, 26 Apr 2005 15:14:43 -0600

> can't reliably interoperate with yours.
What if you get this:

<entry>
<id>whetever</id>
<title>So Caleb is Lindsey's father</title>
<summary>DNA testing has proven Caleb is Lindsey's father</summary>
</entry>

What does this mean?

a) a title and summary only entry
b) a full content entry with the content missing
c) a summary and extension element entry with dc:modified missing
etc.
etc.
etc.

As long as an entry meets the requirements of the spec, if an element 
isn't there, the consumer (unless it has some special out-of-band 
knowledge) has to assume that the entry is complete.  If anything that 
the publisher intended to have there is missing, then their software 
has a bug or they've misconfigured it, and ensuring that their buggy or 
incorrectly configured software interoperates well is beyond the scope 
of the spec, is it not?

---

From: Graham <[email-masked]>
Date: Tue, 26 Apr 2005 22:24:38 +0100

On 26 Apr 2005, at 9:53 pm, Robert Sayre wrote:

> On 4/26/05, Graham <[email-masked]> wrote:
> I have no idea what you're talking about. Do the feeds on
> craigslist.org interoperate? Yes or No?

Interoperate with what?

If I write an app that needs to know whether an entry had a body that 
was removed or is a title-only feed, it cannot interoperate with Atom 
feeds under Tim's proposal because there is no difference between them. 
This is totally an interoperability issue.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Tue, 26 Apr 2005 17:41:26 -0400

On 4/26/05, Graham <[email-masked]> wrote:
 
> was removed or is a title-only feed, 

uh, what's the difference.

> it cannot interoperate with Atom

Nonsense. None of Atom's elements communicate that information, and
there is no requirement to do so. Next.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 26 Apr 2005 23:51:59 +0100

> This is totally an interoperability issue.

I'm not sure what you're saying is sensible. If you wrote that app, 
you've gone beyond anything Atom format mandates. Getting on board with 
your app would induce bug compatability, not interop.

cheers
Bill

---

From: "Roger B." <[email-masked]>
Date: Tue, 26 Apr 2005 18:48:12 -0500

> That's not good enough. You have to demonstrate an interop problem to

Interop with *what*, Robert? What's the baseline?

No aggregator *requires* a title... one can be synthesized.

No aggregator *requires* an id... links, hashes, and so on do the job
sufficiently for most purposes.

No aggregator *requires* a date... if one's not attached, we can just
slap on the date we acquired the entry.

And so on... I honestly can't think of a single child of atom:entry
that is required for interop. In which case, the only MUST in the spec
would be "atom:entry MUST contain at least one child element of some
kind. Have fun with that."

No one needs Atom for producing a title-and-link feed. It's overkill,
and pointless. The juice in Atom is in the handling of content...
providing for explicit summaries, and clearly defined payload types.

--
Roger Benningfield

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 27 Apr 2005 02:02:43 +0200

> http://www.intertwingly.net/wiki/pie/PaceOptionalSummary

So far I haven’t seen a cogent explanation of the significant
semantics offered by an empty atom:summary inside an otherwise
valid minimum atom:entry (with an atom:id, atom:title, and
atom:link[@rel='alternate']). Near as I can tell, there is no
discernible difference between an empty and an absent summary
(given the presence of the mandatory other information!).

Tentatively +1.

I also suggest that any cogent explanation would need to be put
on record in the spec, to alert implementors to the issues and
guide them to an educated choice. Otherwise, they are likely to
disregard this issue either wilfully or out of negligence.

Regards,
-- 
Aristotle

---

From: Antone Roundy <[email-masked]>
Date: Tue, 26 Apr 2005 18:21:57 -0600

> Interop with *what*, Robert? What's the baseline?

Interop with other Atom processing software.  The spec is the baseline. 
  The requirements of the spec are (hoepfully!) based on what's needed 
to enable apps to share feeds in a useful way.

Let's see how losing an element other than summary might affect 
interop--atom:id.  If entries don't have atom:id, then consumers will 
have to jump through all sorts of hoops to determine whether one entry 
is the same as one seen before, or an updated version of one seen 
before, or something completely new.  Any actions that depend on 
whether Entry A == Entry B or not would be at the mercy of an app's 
ability to correctly divine whether they're the same entry or not.  
Dropping the requirement for atom:id would clearly have a negative 
impact on interoperability.

How would an entry not having neither atom:summary nor atom:content 
cause problems?  "Apps that expect all feeds to have a summary or 
content would choke" isn't a convincing argument because it's circular. 
  If title and link feeds are allowed by the spec, then apps that can't 
handle them are broken.  When their author's become aware that title 
and link feeds are possible, I can't fathom they'd have too much 
trouble fixing their apps.

> providing for explicit summaries, and clearly defined payload types.

So if you don't want to provide a summary or content, go away.  RSS can 
have you?  Atom is only overkill if we require a lot of elements that 
aren't needed for interop.

---

From: Robert Sayre <[email-masked]>
Date: Tue, 26 Apr 2005 20:27:05 -0400

On 4/26/05, Roger B. <[email-masked]> wrote:

> that is required for interop. 

Yeah, I agree. The WG does not, however. They do happen to agree with
me on this issue.
 
> providing for explicit summaries, and clearly defined payload types.

The juice in Atom has little to do with the syndication format. IDs
and dates are big, though.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Wed, 27 Apr 2005 01:33:55 +0100

This argument has a got a bit sidetracked. My position is:

a) I think title-only feeds should be allowed where there's nothing 
sensible to put in the summary or content elements.
b) Under all other circumstances, a summary of some kind should be 
required when atom-based textual content is absent.

The pace as written newly allows the omission of a summary and content 
on the whim of the publisher. It also allows its omission when the 
content of the entry has been placed in a non-atom container. My first 
problem is that neither of these consequences seem intended. My second 
is that it is the interopability issue. I'm within my rights as a 
consumer to reject title-only feeds as not worth bothering with (before 
you condemn this as an arbitrary decision, bear in mind the current 
Atom spec makes the same judgement). The atom spec would not give 
publishers fair warning of this. This is why I think it makes more 
sense as a "SHOULD" requirement.

(btw The list of scenarios reprinted in the Pace doesn't mention 
whether you MAY include atom:summary outside the MUST cases)

Graham

---

From: Sam Ruby <[email-masked]>
Date: Tue, 26 Apr 2005 22:08:44 -0400

Graham wrote:
> you condemn this as an arbitrary decision, bear in mind the current Atom 
> spec makes the same judgement). The atom spec would not give publishers 
> fair warning of this. This is why I think it makes more sense as a 
> "SHOULD" requirement.

Well stated.  I'd also add that apparently summary SHOULD be non empty 
in all of the cases where it is currently required as well as one new 
case: the case where the content is empty.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Tue, 26 Apr 2005 22:15:52 -0400

On 4/26/05, Sam Ruby <[email-masked]> wrote:
> > on the whim of the publisher. 

That's right.

> > I'm within my rights as a
> > spec makes the same judgement). 

It is arbitrary. My point is that the spec does not reflect consensus
in this working group or help interop. You're within your rights to
reject anything, you just want the spec to back you up, and that's
ridiculous.

> > The atom spec would not give publishers

Nonsense. Never. There are plenty of people here disagreeing with you.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Tue, 26 Apr 2005 22:29:39 -0400

On 4/26/05, Tim Bray <[email-masked]> wrote:

> 
> Paul & I are gonna watch a little more debate and then
> time in this. 

Yeah, so now Sam and Graham are off making up requirements to add to
the spec. This is over and its a waste of the WG's time.

Let me summarize:

MUST: Sam
SHOULD: Graham, Roger
Eh: Bill
MAY: Myself, James T, Antone, Eric, Julian, Martin, Aristotle

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Tue, 26 Apr 2005 22:34:29 -0400

> Nonsense. Never. There are plenty of people here disagreeing with you.

If you attempt to syndicate a contentless and summaryless entry, there 
will be people who drop it on the floor.  It doesn't matter how many 
people write software that behaves otherwise, it is a reality that some 
will behave this way.

 From RFC 2119:

    SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

I am willing to concede that there are valid reasons in particular 
circumstances to ignore the requirement for a summary.  Are you willing 
to concede that there are implications to such a decision that must be 
understood and carefully weighed before chosing to omit a summary?

- Sam Ruby

---

From: James Tauber <[email-masked]>
Date: Wed, 27 Apr 2005 02:54:02 -0400

> understood and carefully weighed before chosing to omit a summary?

(I know this was addressed to Robert, but...)

While I agree that the implications of a decision to omit a summary need to
be understood and carefully weighed by the feed author, I don't believe that
mandating the summary element actually achieves this.

I would rather someone with a titles-only feed just not have a summary
rather than them try to subvert the requirement of the spec by saying
<summary/> or (worse, if it is required to be non-empty) <summary>some
useless text just put here to appease the atom spec</summary>

If someone omits a summary, it is either intentional or not. The spec can
either mandate the summary or not (perhaps encouraging it via a SHOULD):

A. If omission is unintentional and the spec mandates it, then a validator
will pick the unintentional omission.

B. If the omission is unintentional and the spec doesn't mandate it, then a
validator could still optionally warn the user.

C. If the omission is intentional and the spec doesn't mandate it, the feed
author is free to just omit it (and turn off a warning a validator might
provide)

D. If the omission is intentional and the spec does mandate it, then the
feed author will just subvert this requirement with an empty summary or one
with useless text.

BC seem more acceptable to me than AD (calendarial puns unintentional)

James

---

From: Brett Lindsley <[email-masked]>
Date: Wed, 27 Apr 2005 05:21:52 -0500

One reason for title only feeds is to address bandwidth limited devices. 
The
server I set up provides the same feed in two different formats - one title
only and the other with title/summary/etc. The end client can decide which
feed it wants to work with based on its capabilities; however, both 
feeds need
to be Atom spec compliant. The only thing needed for interop is some minimal
useful information to indicate what the entry is (Title), the ID to identify
uniqueness and a time stamp (updated) to indicate time ordering. Everything
else simply adds more richness to the entry; some may be used by the end
client and some may not. For example, sending entries with summarys may not
be of any value to a device with limited display/storage capabilities, 
so why require
it when it only chews up transmission bandwidth? Brett Lindsley, 
Motorola Labs.

---

From: Sam Ruby <[email-masked]>
Date: Wed, 27 Apr 2005 06:35:21 -0400

James Tauber wrote:

> mandating the summary element actually achieves this

So.. can we agree on SHOULD?

- Sam Ruby

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 27 Apr 2005 11:33:45 +0100

> BC seem more acceptable to me than AD (calendarial puns unintentional)

I agree with this line of thought - and great pun!

It's one thing to reduce optionality, it's another to encourage garbage 
out. Sam mentioned earlier that people will drop title-only feeds on the 
floor; befoe wondering whether that's reasonable behaviour do we have a 
list anywhere?

cheers
Bill

---

From: "James Tauber" <[email-masked]>
Date: Wed, 27 Apr 2005 19:40:24 +0800

> So.. can we agree on SHOULD?

Well, given how close what I've said I agree to is to the wording of RFC
2119, I'll look inconsistent if I don't say 'yes' :-)

I could certainly live with SHOULD.

James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 27 Apr 2005 15:09:38 +0200

> So.. can we agree on SHOULD?

+1. My previous tentative +1 for MAY is hereby withdrawn.

Regards,
-- 
Aristotle

---

From: Antone Roundy <[email-masked]>
Date: Wed, 27 Apr 2005 08:10:43 -0600

On Wednesday, April 27, 2005, at 04:21  AM, Brett Lindsley wrote:
> One reason for title only feeds is to address bandwidth limited 
> devices. The
> feed it wants to work with based on its capabilities;

This raises a few questions:

1) How does one indicate the existence of variants?
2) Can/should the variant feeds use the same atom:ids for variants of 
the same entries?
3) How does a client select a preferred variant?
4) How does an aggregator discover the "complete" and/or 
"authoritative" variant of an entry?

Here's a quick idea for how this might be done. Especially at this late 
stage, this would almost certainly go in an extension. But I bring it 
up now because of the issue raised by question #2 could mean that the 
extension MIGHT be contradicting the Atom spec if it said to use the 
same atom:id for multiple variants, depending on one's interpretation:

<feed>
	<link rel="variants" ... /><!--this is a link to a file listing 
variants-->
	<link rel="complete" ... /><!--this is a link to a variant which 
contains all of the elements found in any variant--it's conceivable 
that no such variant may exist in some cases--they might just be 
alternatives--or there could be more than one--thus this concept may 
not be useful-->
	<link rel="authoritative" ... /><!--this is a link to the feed that 
the publisher considers to be the authoritative version from which the 
others are derived-->
	...
</feed>

<variants xmlns="...">
	<variant href="..."><!--the entries in this variant contains the 
following elements...-->
		<elem>title</elem>
		<elem>id</elem>
		<elem>updated</elem>
		<elem>link[@rel="alternate"]</elem>
	</variant>
	<variant href="..."><!--this could be "complete"-->
		<elem>title</elem>
		<elem>id</elem>
		<elem>updated</elem>
		<elem>link[@rel="alternate"]</elem>
		<elem>content[@type="html"]</elem>
	</variant>
	<variant href="..."><!--this also could be "complete"-->
		<elem>title</elem>
		<elem>id</elem>
		<elem>updated</elem>
		<elem>link[@rel="alternate"]</elem>
		<elem>content[@type="xhtml"]</elem>
	</variant>
</variants>

---

From: Robert Sayre <[email-masked]>
Date: Wed, 27 Apr 2005 10:38:03 -0400

> people write software that behaves otherwise, it is a reality that some

Do you have an example?

> understood and carefully weighed before chosing to omit a summary?

What are the interoperability considerations that must be carefully
weighed? I think the "full implications" you're worried about are
non-technical.

Robert Sayre

---

From: Brett Lindsley <[email-masked]>
Date: Wed, 27 Apr 2005 09:37:39 -0500

I used title="titles" and title="full" to indicate the varients in the 
feed discovery
while maintaining compliance with the current spec. The user must select 
which
feed to use.

One assumption I am making is that the updated time for both the title only
and the full entry are the same. If I have a title only entry and I want 
the full
entry, I just use the updated time to indicate a time range in the full 
entry
feed. I also use the same ID and verify the returned full entry matches the
ID of the title only entry.

Brett Lindsley, Motorola Labs

Antone Roundy wrote:

> Here's a quick idea for how this might be done. Especially at this 
> late stage, this would almost certainly go in an extension. But I 
> bring it up now because of the issue raised by question #2 could mean 
> that the extension MIGHT be contradicting the Atom spec if it said to 
> use the same atom:id for multiple variants, depending on one's 
> interpretation:
>
> <feed>
>     <link rel="authoritative" ... /><!--this is a link to the feed 
> that the publisher considers to be the authoritative version from 
> which the others are derived-->
>     ...
> </feed>
>
> <variants xmlns="...">

---

From: Eric Scheid <[email-masked]>
Date: Thu, 28 Apr 2005 00:53:05 +1000

> the publisher considers to be the authoritative version from which the

why not

<feed>
    <link rel="alternate" type="application/xml+atom title="minimal"/>
    <link rel="alternate" type="application/xml+atom title="authoritative"/>
    <link rel="alternate" type="application/xml+atom title="summmaries"/>
    ...
</feed>

and the client agent can then present these to the user to select from.

e.

---

From: Antone Roundy <[email-masked]>
Date: Wed, 27 Apr 2005 09:20:45 -0600

> and the client agent can then present these to the user to select from.

At present:

    atom:feed elements MUST NOT contain more than one atom:link
    element with a rel attribute value of "alternate" that has the
    same type attribute value.

...but if that were something other than "alternate"...

The question is, do you want this to be automatically discoverable or 
only user selectable?  Finding the authoritative variant automatically 
might be important for some applications.  Finding a variant with a 
specific set of elements and as few others as possible might be 
important for other applications.  That COULD be done by downloading 
and inspecting each variant.

...but I'm really speculating here.  The main reason I brought this up 
now was because, given that some people are already publishing variant 
feeds, it might be good to answer the question of whether using the 
same atom:id in variants of an entry is legal, and if so, how such 
things should/could be handled.

---

From: Walter Underwood <[email-masked]>
Date: Wed, 27 Apr 2005 09:09:34 -0700

--On Wednesday, April 27, 2005 02:02:43 AM +0200 "A. Pagaltzis" <[email-masked]> wrote:
>
> So far I haven?t seen a cogent explanation of the significant
> valid minimum atom:entry.

It should be obvious. It means that when you summarize the content,
you get nothing at all. It is an effectively, but not literally,
content-free entry.

I'm not being entirely silly here. We could distinguish between
"I am not providing a summary" (no element) and "the summary is void"
(empty summary).

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 27 Apr 2005 17:08:04 +0100

> "I am not providing a summary" (no element) and "the summary is void"

We could; but isn't that only really needed if we mandate the empty 
element, ie if we mandate the XML variant of SQL's true/false/null?

cheers
Bill

---

From: Walter Underwood <[email-masked]>
Date: Wed, 27 Apr 2005 09:58:24 -0700

> weighed? I think the "full implications" you're worried about are

It certainly makes the feed much less useful for some kinds of applications.
I work on a search engine, and, for us, a titles-only feed is very different
one with content or summaries. A titles-only feed is basically a pretty
version of "ls". The engine follows the links, but does not index the
document. With summaries or content, the feed is a document in its own
right, and it makes sense to index it under its own URL.

A search engine won't ignore a titles-only feed, but it is less likely
to treat it as a first-class document.

Now I'm going to go re-read the PACE to see where I am on +/-.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 27 Apr 2005 20:55:27 +0200

+1

This means I agree with Rob that these [1] three entries mean different 
things.

[1] http://www.imc.org/atom-syntax/mail-archive/msg14432.html

-- 
Thomas Broyer

---

From: Brett Lindsley <[email-masked]>
Date: Wed, 27 Apr 2005 14:22:32 -0500

This gets back to the brief discussion I had with Henry Story about the
attributes of the link vs the attributes of what the link points to. A 
single
resource (theoretically) exists but there may be various representations 
of it.
How do we specifiy this with the current link model?

My initial thoughts with respect to enclosures is  a
single resource (e.g. an image) but it may have various representations
(e.g. resolutions, etc.). We could have a single "alternate"
link (link attribute) but several URLs, each with its own attributes 
(minimal,
authoritative, etc.).

But I don't want to reopen this issue...

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 27 Apr 2005 21:59:07 +0200

Antone Roundy wrote:
>> devices. The server I set up provides the same feed in two 
>> different formats - one title only and the other with 
>> title/summary/etc. The end client can decide which feed it wants to
>>  work with based on its capabilities;
> 

link@rel="alternate"
or using a custom (read: extension) relations
or using extension elements.
See also my comments below on 3).

> 2) Can/should the
>  variant feeds use the same atom:ids for variants of the same
> entries?

Yes, IMO, as they identify the same entry, with different, more or less 
rich, representations.
However, does the current draft explicitly say that or can it be 
understood that different representations of the same entry 
must/should/may have different ids?
This reminds me of link@rel="alternate" vs. link@rel="alternate-of" 
discussion...

> 3) How does a client select a preferred variant?

Good question, but it seems to me that it's beyond the scope of the 
current (format) spec. It should IMO go with autodiscovery.

> 4) How does
> an aggregator discover the "complete" and/or "authoritative" variant
> of an entry?

Autodiscovery?

IMO, all this should be recorded and discussed later when the 
autodiscovery spec will be on air.

-- 
Thomas Broyer

---

From: Andreas Sewe <[email-masked]>
Date: Wed, 27 Apr 2005 16:39:15 -0600

Thomas Broyer wrote:
> link@rel="alternate" or using a custom (read: extension) 
> relations or using extension elements. See also my comments 
> below on 3).

I'll just stop lurking for a minute to make the following
suggestion:

Why do you not simply follow the lead of HTML [1] on this issue,
which uses a list of values--to express, e.g., link@rel=
"alternate stylesheet"?

So maybe something along the lines of link@rel="alternate
summary" could work for Atom, too.

Regards,

Andreas

[1] <http://www.w3.org/TR/html4/types.html#type-links>

---

From: "Roger B." <[email-masked]>
Date: Wed, 27 Apr 2005 23:45:24 -0500

> Do you have an example?

Robert: I'm an example. I also drop title-free feeds (see Scripting
News)... given the nature of the app, a feed without titles or content
is just worthless.

That doesn't mean I have anything against content-free feeds for
specific applications. After all, as you pointed out, I produce some.
In fact, that's why I'm pro-SHOULD in this case; a weblog or wiki feed
(Atom's two primary targets) should contain some form of content. But
if you know what you're doing, and have no other choice, then drop it
and cross your fingers.

> weighed?

Apps that expect content won't get any. I haven't checked things out
in a while, but once upon a time, Newsgator-in-Outlook would use the
item's link as the content for a content-free feed. Newzcrawler,
meanwhile, automatically forwards the user (via the integrated
browser) to the link. And as I've already mentioned, I'll drop the
items entirely.

The publisher will therefore face unpredictable results relating to a
key part of aggregator functionality... that's definitely worthy of a
SHOULD.

--
Roger Benningfield

---

From: Robert Sayre <[email-masked]>
Date: Thu, 28 Apr 2005 01:39:05 -0400

> News)... given the nature of the app, a feed without titles or content

That's fine, but we're not here to tailor the format to your app. I've
gotten feedback from embedded device developers complaining that XHTML
requires them to do more parsing than their app can handle, for little
practical benefit (for them). Note that we're also giving them the
short end of the stick with this requirement.

> (Atom's two primary targets) should contain some form of content.

This is the assertion I have a problem with, and the opinions
expressed by others echo my gripe.

> But

Well, now we're just back to the sorts of feeds that are supposedly
perfectly ok on the condition that they contain an empty summary
element. We seem to be forgetting that RSS feeds were initially for
headlines and links alone. It's obvious that full-content feeds are
much more popular now, but there is no definition of "syndication" or
"RSS" in common use that precludes title-only feeds.

> key part of aggregator functionality... that's definitely worthy of a

Publishers face unpredictable results in any case. We don't mandate
that apps do anything with data they receive, so they are free to
decide the summary is too short and showing the web page would be
better (experiment with this in RSS Bandit). By default, Mozilla
Thunderbird doesn't show RSS summaries or Atom content when they are
present. Instead it behaves as NewzCrawler does in all cases.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Thu, 28 Apr 2005 17:00:15 +1000

> News)... given the nature of the app, a feed without titles or content

I'm also an example - if I discover that a feed I once loved for it's tech
content is now given over to endless cat pictures, or discussion of
politics, then I too will drop that feed post haste. Even if it does have a
summary.

Sorry, what was your point again?

e.

---

From: Sam Ruby <[email-masked]>
Date: Thu, 28 Apr 2005 03:54:00 -0400

Robert Sayre wrote:
> That's fine, but we're not here to tailor the format to your app.

Robert: why did you ask for an example?

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Thu, 28 Apr 2005 04:18:26 -0400

> Robert: why did you ask for an example?

To find out about any technical issues, not to hear Roger repeat himself.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 28 Apr 2005 10:11:27 +0100

>> http://www.intertwingly.net/wiki/pie/PaceOptionalSummary

I think I'm the only 0 in this. After watching the debate progress over 
the last few days, I'm altering my position to +1.

cheers
Bill

---

From: "Roger B." <[email-masked]>
Date: Thu, 28 Apr 2005 06:16:45 -0500

> Sorry, what was your point again?

Eric: The point was that the *application* drops title- or
content-free entries. It never inserts them into the database. They go
poof.

--
Roger Benningfield

---

From: "Roger B." <[email-masked]>
Date: Thu, 28 Apr 2005 06:46:42 -0500

> That's fine, but we're not here to tailor the format to your app. 

Robert: Seriously, dude. C'mon.

I don't care what little slap-fight you want to have with Sam, or
Graham, or whoever else you figure is wronging the sublime rightness
of your position. That's your thing, and welcome to it.

You're not the first one to feel like "consensus" led Atom somewhere
it had no business going. If you want to sit around and bitch about
it, I'll might even join in. I was most unhappy with how things went
in the XML-RPC vs. REST debate, for example. I've moved on, but I can
at least sympathize.

But you asked a question, and I answered it. Honestly,
straightforwardly, and without an weasel-words. I did not ask anyone
to tailor anything to anything. Try that silly crap with others if you
must, but spare me.

> I've

If their embedded devices can't easily produce XHTML, then they don't
have to do so. If their devices can't easily consume XHTML, they can
either strip it or drop it. Again, the one thing Atom actually brings
to the table over RSS is that content is clearly flagged. So where's
the problem?

(Or did someone slip something into 08 that says summaries must be XHTML?)

> expressed by others echo my gripe.

Which part is the assertion that's causing you trouble? 'Cause half is
in the charter, and the other half is one of those obvious things that
Paul referenced.

> element.

Again, I support a SHOULD on summary. Not just adding an empty
element... allowing publishers to drop it entirely, as long as they're
aware they're doing something that will have an impact on the primary
functionality of feed-consuming applications.

Not that I think SHOULD is a good idea in this case. I just don't see
the point in arguing about it incessantly, and SHOULD covers most of
the bases.

--
Roger Benningfield

---

From: Robert Sayre <[email-masked]>
Date: Thu, 28 Apr 2005 09:53:11 -0400

> Robert: Seriously, dude. C'mon.

You're right, that was too snippy. 

> functionality of feed-consuming applications.

Your argument is mostly consistent. I'll try to explain why SHOULD
will create problems that don't exist today. Let's take del.icio.us.
Sometimes, their entries have descriptions. Sometimes, they don't.
Your SHOULD allows competitors to turn off their feeds at any time,
and point to the spec as justification. Even worse, it could be "oh,
some of their entries are buggy, so we drop those." I doubt your
intent is anything nearly that malicious, and you might be right that
the feeds in question suck, but using a SHOULD to back up that action
is exactly what we want to avoid. It might even be possible to write a
naive parser that actually malfunctioned on such feeds.

Basically, if what you say is true, we don't need to enforce a summary
at all. It'll take care of itself, like email and even HTML eventually
did (it's possible to create an entire page in Flash, but not
particularly effective in the market). If these sorts of feeds are
legitimate for a certain style of application, a SHOULD is bound to
bring questions my way wondering "what does that SHOULD *really*
mean?". If that were to happen, the only ethical thing to do would be
to refer the question to Mark Nottingham. I've begun training an email
filter to forward questions to him ;)

That is not a problem worth creating in return for advocating the type
of feed we think is cool right now.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Tue, 26 Apr 2005 17:41:26 -0400

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 26 Apr 2005 23:51:59 +0100

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 26 Apr 2005 23:51:59 +0100

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Tue, 26 Apr 2005 20:27:05 -0400

Robert Sayre

---

From: Graham <[email-masked]>
Date: Tue, 26 Apr 2005 22:24:38 +0100

Interoperate with what?

Graham

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 26 Apr 2005 23:51:59 +0100

cheers
Bill

---

From: Graham <[email-masked]>
Date: Tue, 26 Apr 2005 22:24:38 +0100

Interoperate with what?

Graham

---

From: Robert Sayre <[email-masked]>
Date: Tue, 26 Apr 2005 20:27:05 -0400

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 26 Apr 2005 23:51:59 +0100

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Tue, 26 Apr 2005 20:27:05 -0400

Robert Sayre

---

From: Graham <[email-masked]>
Date: Tue, 26 Apr 2005 22:24:38 +0100

Interoperate with what?

Graham

---

From: Robert Sayre <[email-masked]>
Date: Tue, 26 Apr 2005 20:27:05 -0400

Robert Sayre

---

From: Graham <[email-masked]>
Date: Tue, 26 Apr 2005 22:24:38 +0100

Interoperate with what?

Graham

---

From: Henry Story <[email-masked]>
Date: Fri, 29 Apr 2005 00:39:03 +0200

I'll +1 on MAY.

---

From: Brett Lindsley <[email-masked]>
Date: Fri, 29 Apr 2005 08:28:20 -0500

Although it is not a show stopping problem, the link has some issues.
This has been previously commented on by others. In particular,
some of the attributes refer to the link (rel, title) whereas other 
attributes
refer to what the link points to (length, type). There has also been
some interest about multiple links to various representations of
the same resource.

The following situation is not unrealistic: Assume an entry describes
a major event. Enclosures may have different representations of this
event such as a SMIL slide show, an audio only mp3 or a
video clip. These are all the same resource but has different 
representations.
The end client can then download the one that is most appropriate for
its rendering capabilities, storage capacity, etc.

The link would look something like:

<link rel="enclosure" title="major event">
    <representation href="zzz" type="application/smil" length="80000"/>
    <representation href="xxx" type="audio/mpeg" length="8000000"/>
    <representation href="yyy" type="video/mpeg" length="80000000"/>
</link>

To maintain compatibility with the current spec, one could limit the
number of representations to one for particular types of rel's.

Brett Lindsley, Motorola Labs.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 29 Apr 2005 18:12:43 +0200

Please be aware that I’m not in any camp right now. I’m still
vacillating, trying to understand the implications of this issue.
I am leaning against MUST, but that’s not a done deal, and I’m
not at all sure about MAY vs SHOULD.

* Robert Sayre <[email-masked]> [2005-04-28 16:05]:
> Your SHOULD allows competitors to turn off their feeds at any
> time, and point to the spec as justification.

Does it? Doesn’t SHOULD mean that it is perfectly within rights
of the producer to drop the requested item on the floor?

> Even worse, it could be "oh, some of their entries are buggy,
> so we drop those."

Now that, I could see (albeit not with that wording). By my
reading of RFC2119, it is not entirely clear whether consumers
would be required to process entries lacking both summary and
content.

Am I correct?

In that case the problem lies in the asymmetry between producers
and consumers of feeds; since the Atom spec adresses both, this
could be clarified by adding that consumers MUST accept
title-only entries, but of course, that would be implied if
inclusion of a summary was OPTIONAL.

So I guess the options are:

1. RECOMMEND providing a summary and REQUIRE processing entries
   whether one is provided or not
2. Make a summary OPTIONAL even in absence of content, and only
   informally mention the considerations feed providers should be
   aware of (possibly elsewhere).

Is that right so far?

Assuming my reasoning is sound and these are the choices, I’d
still lean towards MAY, since verbiage is comparable in either
case, but choice 2 simplifies the core spec.

Regards,
-- 
Aristotle