Subject: PaceTextShouldBeProvided

From: Antone Roundy <[email-masked]>
Date: Thu, 5 May 2005 08:58:42 -0600

+1 except for one thing: In section 4.1.2, I'd suggest something along 
these lines:

atom:entry elements which do not contain an atom:content element, or 
whose atom:content element's type attribute indicates a MIME media 
type, SHOULD contain an atom:summary element.

---

From: Sam Ruby <[email-masked]>
Date: Thu, 05 May 2005 11:27:58 -0400

Antone Roundy wrote:
> whose atom:content element's type attribute indicates a MIME media type, 
> SHOULD contain an atom:summary element.

Incorporated.  Thanks!

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Thu, 5 May 2005 11:27:50 -0400

> type, SHOULD contain an atom:summary element.

This Pace is incompatible with PaceOptionalSummary and incomplete. -1.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Thu, 05 May 2005 12:47:24 -0400

> This Pace is incompatible with PaceOptionalSummary and incomplete. -1.

Something a little less curt would be appreciated.

The stated abstract of PaceOptionalSummary (i.e., "removing the 
requirement for <atom:summary>") is met.  In your mind, this equates to 
completely optional.  That has yet to be conclusively established.

What concerns me more, however, is that interoperability issues that 
PaceOptionalSummary not only creates, but also uncovered during its 
discussion.

Unless there is some plan for addressing these interoperability issues 
(and by that, I mean something more constructive than "That's fine, but 
we're not here to tailor the format to your app."), then perhaps BOTH 
paces are incomplete.

There are a number of ways to finesse the identification of the issue 
into the spec.  For example, take a look at how Tim worded 
PaceAllowDuplicateIDs.  Producers are put on effectively put on notice 
that if they include multiple entries with the same ID, that some or all 
of them may be ignored.

How should we convey a similar sentiment about the reality that entries 
without a readily available textual representation may suffer the same fate?

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Thu, 5 May 2005 13:23:15 -0400

> completely optional.  That has yet to be conclusively established.

Well, consider the name of the Pace, and then consider this sentence:

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
                truly optional.

It would be deeply bogus to accept a Pace whose sole action was to
remove a normative requirement, and simultaneously accept a Pace that
puts it back in. Seems obvious to me.

> PaceOptionalSummary not only creates, but also uncovered during its

We know exactly what issues optional content has, because all of the
other formats have it.

> we're not here to tailor the format to your app."), then perhaps BOTH

Let's enumerate the issues, rather than insist they exist. Frankly, I
seriously doubt that anyone with customers will outright reject a
title-only feed.

> that if they include multiple entries with the same ID, that some or all

I don't think PaceAllowDuplicateIDs successfully finessed the issue.

> without a readily available textual representation may suffer the same fate?

So, we're looking for some way to say "provide as much information as
you can." The problem with saying SHOULD is that we purport to know
how much information the publisher can provide. It would be very easy
to explain this issue in the spec, and I have no objection to doing
so. Why do we need the RFC2119 words?

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Thu, 5 May 2005 14:02:13 -0400

On 5/5/05, Graham <[email-masked]> wrote:
> On 5 May 2005, at 6:23 pm, Robert Sayre wrote:
> 
> Not really. Assuming PaceOptionalSummary is accepted, there are two
> completely valid outcomes:
> 
> 1. PaceTextShouldBeProvided rejected => summaries are not required,
> and textual content is not encouraged
> 2. PaceTextShouldBeProvided accepted => summaries are not required,
> but textual content is encouraged
> 
> I don't see a conflict there. What's wrong with accepting two similar
> paces because one corrects the flaws in the other?

Graham, that's just not true. It wasn't called
PaceSummariesAreNotRequired, was it? It materially changes the only
action PaceOptionalSummary takes. They are not compatible.

In fact, let's get the chairs to clarify this.

> > so.
> SHOULD here means "must unless you absolutely can't". 

 We've covered lots of perfectly valid reasons not to include a
summary, and we've heard from implementors that actually prefer its
absence.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Thu, 05 May 2005 15:37:18 -0700

> In fact, let's get the chairs to clarify this.

Speaking not as the chair but as an interested WG member,  I read them 
about eight times and I do not understand why they are in conflict.  
Someone please explain, as simply as possible, what the problem is, 
because I just don't get it.  On the face of it, I am inclined to be +1 
to both PaceOptionalSummary and PaceTextShouldBeProvided.

Note: I totally fail to understand the "Notes" bit at the end of 
PaceTextShouldBeProvided.  It is underspecified to the extent that I 
can't figure out what language change it is actually saying is 
necessary.

Basically, allowing title-only feeds seems OK to me, and encouraging 
people to provide text also seems OK to me, so what's the problem?  In 
fact, these seem pretty orthogonal; it seems quite plausible that one 
could like either of these without liking both.  -Tim

---

From: Tim Bray <[email-masked]>
Date: Thu, 05 May 2005 16:18:09 -0700

On May 5, 2005, at 3:52 PM, Robert Sayre wrote:

> Everything in the proposal section is fine with me, as well. It's that
> "Notes" section that's the problem.
>
> That section says is "If PaceOptionalSummary is 'accepted', this Pace
> changes summary to SHOULD." That's OK to propose, but you can't accept
> both of them. They conflict.

No it doesn't, it says something about inserting the phrase "...is 
either not present or..." which, by the way, I don't understand.  Are 
we looking at the same document?

>> people to provide text also seems OK to me, so what's the problem?
>
>                                 Current spec: MUST contain a summary
>         after PaceOptionalSummary: MAY contain a summary
> after PaceTextShouldBeProvided: SHOULD contain a summary

So what you're actually objecting to is the last part of the Pace 
before the "Impacts" section, that wants 4.1.2 to say that summary 
SHOULD be there if Content is absent.  Or am I missing something? -Tim

---

From: Graham <[email-masked]>
Date: Thu, 5 May 2005 18:49:23 +0100

> We know exactly what issues optional content has, because all of the

Yes, and we don't like it. A basic title only feed gives you fuck all  
to work with - it displays poorly when mixed with rich-content feeds,  
it isn't searchable because there aren't many keywords in the title,  
etc etc. They cause all sorts of problems.

> to explain this issue in the spec, and I have no objection to doing

SHOULD here means "must unless you absolutely can't". That seems like  
a perfectly dandy explanation of the intention of encouraging high  
quality feeds.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Thu, 5 May 2005 19:31:14 -0400

> we looking at the same document?

Ah, it's been updated since I last looked. The proposed text for 4.1.2
didn't used to account for an absent content element.
 
> SHOULD be there if Content is absent. 

Yes. If that SHOULD goes through, it becomes OK to write an Atom
Processor that catches fire when summary and content are both absent.
That is not what the folks who supported PaceOptionalSummary were
advocating. They conflict.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Thu, 05 May 2005 22:57:32 -0400

> didn't used to account for an absent content element.

The notes section is now gone.  PaceTextShouldBeProvides now contains a 
proper superset of the instructions contained in PaceOptionalSummary.

Perhaps now we can get beyond discussing alleged incompatibilities.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Thu, 5 May 2005 18:52:09 -0400

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Thu, 5 May 2005 23:26:37 -0400

> Perhaps now we can get beyond discussing alleged incompatibilities.

PaceTextShouldBeProvided: SHOULD have a summary
        PaceOptionalSummary: MAY have a summary

Pick one.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Fri, 6 May 2005 04:45:47 +0100

>         PaceOptionalSummary: MAY have a summary

No, Robert:

Current situation: MUST have a summary

PaceOptionalSummary: No explicit opinion

PaceOptionalSummary simply says remove the "MUST", it doesn't say  
what it should be replaced with.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Thu, 5 May 2005 23:49:15 -0400

> what it should be replaced with.

What part of OPTIONAL don't you understand? 

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 06 May 2005 13:35:59 +0100

> to both PaceOptionalSummary and PaceTextShouldBeProvided.

1. The pace's rationale has claims which have already been refuted by 
Robert and others in the discussion on optional summaries:

  "Encourage interoperability and accessibility"

this rationale has no merit, imo.

2. It has a bias that is squarely aimed at title only feeds, which is 
the outcome of PaceOptionalSummary

  "Unfortunately, there are also existence proofs of title-only feeds"

it clearly takes a shot across the bows of PaceOptionalSummary.

3. It's the kind of spec text we have rejected in the past as 
impletation specific and/or "best current practice" guidance:

  "those that follow these suggestions will find that their feeds are 
useful to a wider audience than they would be otherwise."

we have a decision making legacy that speaks for itself, this is not 
demstrated to be a special case we ought to cater for.

4. It would appear to contradict PaceOptionalSummary by highlighted that 
  legal usage as bad practice. That's contradictory in spirit, and 
personally speaking it's the kind of wording and deliberate vagueness 
that infuriates me about software specs. fFutzing about like this is 
showing poor form to the users of the spec

2 alone should be enough for you. Technically these things are not in 
contradiction, in sprit they are.

I'm on the record already here:

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

cheers
Bill

---

From: Sam Ruby <[email-masked]>
Date: Fri, 06 May 2005 08:55:10 -0400

> useful to a wider audience than they would be otherwise."

Um, that text is not part of the proposal.  It is part of the rationale.

- Sam Ruby

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 06 May 2005 15:31:23 +0100

> Um, that text is not part of the proposal.  It is part of the rationale.

I know. I don't see the point of considering PaceTextShouldBeProvided if 
the rationale doesn't hold up.

cheers
Bill

---

From: "Roger B." <[email-masked]>
Date: Sat, 7 May 2005 02:01:53 -0500

> Processor that catches fire when summary and content are both absent.

Robert: Nothing about either pace will make it "not OK" to drop
content- and summary-free entries on the floor, or come to a full stop
when they're encountered. Such feeds would be completely useless in
some apps, and therefore deserve to be tossed.

PaceOptionalSummary simply enables an infinite loop of "talk to the
other guy about that" responses to user questions, while
PaceTextShouldBeProvided says that the tie goes to the aggregator.

Kinda funny when you look at it that way, given the heated discussion
on the subject. They could both be rolled into a single
PaceWhoYouGonnaBlame and save everyone unnecessary reading.

--
Roger Benningfield