Subject: PaceOptionalSummary

From: Antone Roundy <[email-masked]>
Date: Thu, 5 May 2005 09:00:21 -0600

+1.

...oh, and the wording I just suggested for part of 
PaceTextShouldBeProvided would depend on this also being accepted.

---

From: Sam Ruby <[email-masked]>
Date: Mon, 09 May 2005 08:19:38 -0400

> PaceTextShouldBeProvided would depend on this also being accepted.

With deep regret, I'm going to express my -1 on PaceOptionalSummary.
Not because I object to the text expressed in the proposal section.
In fact, I clearly do not as I lifted large sections of it to be placed 
into PaceTextShouldBeProvided.

No, it is because the author of PaceOptionalSummary has made it clear
that he interprets the two paces to be incompatible, so each and every
+1 for PaceOptionalSummary is a vote against
PaceTextShouldNotBeProvided.  Despite wording that accompanied several
of these +1's, like the wording describe above.

I also feel the need to express deep dismay at the way that author of
PaceOptionalSummary has been pursuing a scorched earth approach whereby
everybody who expresses an opinion to the contrary is viciously attacked
for doing so.  I believe that this has significantly hampered the 
ability of the work group to hold a reasonable discourse on the subject.

Despite this, I have attempted to see if there was some common ground to
be found.  I drafted up a Pace, and offered a few suggestions.  It has
since become clear to me that PaceOptionalSummary is being pursued in a 
winner take all manner.

As such, I see no other path than to offer my -1 on the Pace.  Face
down, arms and legs outstretched, in the middle of the road.

One thing I would like those who advocate PaceOptionalSummary to the
exclusion of all other Paces on the subject to consider... what happens
if the chairs determine that consensus can't be found on either of these
paces?  Look at the current wording of draft-08.  Is that what you
really want?

We can do better.

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Mon, 9 May 2005 13:37:33 +0100

> ability of the work group to hold a reasonable discourse on the  

Plus fucking one.

> down, arms and legs outstretched, in the middle of the road.

-1 also.

Graham

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 09 May 2005 14:30:02 +0100

Sam Ruby wrote:
> PaceTextShouldNotBeProvided.  

I don't think the last clause follows.

> down, arms and legs outstretched, in the middle of the road.

Tim asked last week for an explanation as to why the two paces conflict. 
I provided this:

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

I see PaceTextShouldBeProvided as contradictory to PaceOptionalSummary. 
It calls out title-only feeds as unfortunate and I assume from that, we 
are meant to infer a bad practice. You came back to me and pointed out 
that the rationale is not the spec text; I agreed and said the rationale 
is flawed. That's where is was left.

I think, more or less, that PaceTextShouldBeProvided only exists because 
PaceOptionalSummary has not been successfully dismissed. I have no idea 
why title-only feeds are unfortunate, are an interoperability problem, 
or an accessibility problem. In fact I felt we had put the accessibility 
issue to bed weeks ago, but it popped up again in the 
PaceTextShouldBeProvided's rationale.

> paces?  Look at the current wording of draft-08.  Is that what you

If the chairs count it up, I think they could find consensus. I think 
they could have done that a fortnight ago. Or last week. I agree with 
Robert's paraphrasing, that we are drowning in +1s. And I fail to 
understand why this has been dragged out so long. There are a few 
strongly voiced objections, but is that sufficient reason to grind this 
one out?

> We can do better.

I started out 0 and moved to +1 based on the arguments I saw presented 
for and against PaceOptionalSummary and my own thinking. I'm -1 on 
PaceTextShouldBeProvided, and have explained why.  I honestly don't know 
how I can do any better on this.

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Mon, 9 May 2005 10:58:09 -0400

> ability of the work group to hold a reasonable discourse on the subject.

I believe the secretary significantly hampered discourse on this
subject for *months*, by claiming the issue had consensus and was
closed. How did that estimate of consensus pan out?

> paces?  Look at the current wording of draft-08.  Is that what you
 
That's not what will happen. You see, there was only *one* supporter
of that wording.

The WG has spoken very clearly. I'm not sure why this is dragging out.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Mon, 9 May 2005 16:43:30 -0400

Hi Guys!

Did you see this email? Did you notice all the questions about the
technical basis of your position? Maybe you should answer them.

Also, I'm having trouble reconciling your road lying with the
assertion that the two proposals are compatible. How can they be if
their outcomes are so different?

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Mon, 9 May 2005 15:33:36 -0600

> their outcomes are so different?

The change to the spec text proposed by PaceOptionalSummary would also 
be made by PaceTextShouldBeProvided.  In that way, they are compatible. 
  The intents of the authors in writing them was different.  In that 
way, they are incompatible.

The intents of people who gave them +1 are not 100% clear.  My 
interpretation is that if someone gave PaceOptionalSummary a +1, but 
not PaceTextShouldBeProvided, then their intent is close to the author 
of PaceOptionalSummary.  If they gave both a +1, then either they could 
live with either MAY or SHOULD in the proposed change to section 4.1.2, 
or their intent is close to the author of PaceTextShouldBeProvided (and 
they consider the two basically compatible for the reason noted 
above--ie. looking at the proposed changes to the spec, and not 
worrying about the authors' intents). I'm in the former group--okay 
with either MAY or SHOULD.  I'd lean more toward SHOULD if we were to 
come up with a good way to say "if there's content, but it's not in 
atom:content in one of our three special formats, then there SHOULD be 
a summary"--in other words, if one of the following applies:

* atom:content/@type is a MIME type rather than "text", "html" or 
"xhtml"
* there is no atom:content, and some extension element holds the core 
content of the entry

Note that I don't list "no atom:content and no extension element 
holding the content"...that's where I lean towards MAY, because to me, 
the biggest reason for strongly encouraging the use of atom:summary is 
accessibility.  If there's no atom:content or substitute element, then 
nobody is less able to access the content of the entry than anyone 
else, because there is no "content" outside of the metadata elements.

The problem with the above is that bullet point #2 isn't checkable 
without agreement on what constitutes a 
core-content-holding-extension-element.  I don't even want to try to 
come up with language to describe that--I've participated in this group 
too long to be that foolish.

>> PaceTextShouldBeProvided's rationale.

I have no problem with title only feeds.  I myself would be far less 
likely to subscribe to them--or at least they'd have to have 
extraordinarily well-written, informative titles for me to subscribe to 
them in just about all cases--but there are certainly valid uses for 
them.

---

From: "Roger B." <[email-masked]>
Date: Mon, 9 May 2005 17:08:48 -0500

> I have no problem with title only feeds.

I'm -1 on POS, although I wouldn't describe myself as being positioned
in the path of oncoming traffic.

Title-only feeds have valid uses, but they're really out of scope for
a feed format that only exists because it provides a clearer, cleaner
way to deliver content.

--
Roger Benningfield

---

From: Robert Sayre <[email-masked]>
Date: Mon, 9 May 2005 18:15:03 -0400

> them in just about all cases--but there are certainly valid uses for

Do you expect a conformant Atom Processor, such as Jakarta FeedParser,
to successfully process title-only feeds?

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Mon, 9 May 2005 18:24:53 -0400

> a feed format that only exists because it provides a clearer, cleaner

Roger, please don't see this as an attack.

Here's our charter:

----------------------------------
The format must be able to represent:
   ...
    * a feed or channel of entries, with or without enclosed
        content
   ...
----------------------------------

I don't think there's a scope argument here. 

Robert Sayre

---

From: "Roger B." <[email-masked]>
Date: Mon, 9 May 2005 18:54:38 -0500

> Roger, please don't see this as an attack.

Robert: I would have to be one seriously touchy prick to see that as
an attack. Don't sweat it.

> I don't think there's a scope argument here.

That's what I get for using a loaded term. My apologies.

Again, I think title-only feeds are reasonable. And in a
letter-of-the-poorly-phrased-charter sense, they're definitely in
scope. But from a broader "why are we bothering with this?"
perspective, I think they're a bit off the map.

If I create a minimal Atom feed containing a title/link/summary combo,
I will get pretty uniform results across 95% of the aggregators out
there. That's our baseline, the default expectation. If I create a
minimal feed with just title and link, on the other hand, I'm going to
get substantially different results from app to app.

That's no sin, nor is it the end of the world. But it's the kind of
thing that publishers need to understand going in. Does that require a
SHOULD in the spec? Perhaps not. Maybe it just needs a big, bold
paragraph in an implementation guide.

But it feels like a SHOULD to me. Every title-only feed is a support
request waiting to happen, as new users stare at their screens and
wonder why the feed is "broken". And I'm not convinced that aggregator
developers should be the primary heat-takers in such situations... if
you're producing titles-only feeds, you need to know what you're
doing, and you need to be educating users prior to subscription.

For what it's worth, no one needs to feel compelled to address this
post. I'm not trying to hold up the process. I'm just not sure I've
adequately explained my thinking up to now, and wanted to give it
another shot. The end.

--
Roger Benningfield

---

From: Graham <[email-masked]>
Date: Tue, 10 May 2005 12:37:58 +0100

Let's forget about Paces for a minute. Does anyone disagree with the  
principal of recommending publishers include summaries if they have  
them available, and aren't supplying atom:content?

Don't worry about how it might be worded for now, just the principal.

Graham

---

From: Sam Ruby <[email-masked]>
Date: Tue, 10 May 2005 09:12:10 -0400

Robert Sayre wrote:
> closed.

It appears that the scorched earth campaign is destined to continue 
unabated.  It is an interesting theory, now lets explore the facts.

The secretary's job is to schedule the discussion of Paces. 
PaceOptionalSummary was authored on 2005/04/30, and scheduled on 2005/05/05.

PaceOptionalSummary was preceded by PaceCoConstraintsAreBad, which was
authored on 2005/04/06.  It, too, was scheduled in the very next round
of paces.

>>I agree with Robert; it conflicts with PaceOptionalSummary and I doubt
>>> it would exist if PaceOptionalSummary had not make the cut. 
> 
> -1 as well. Doesn't solve a technical problem. It's just gamesmanship.

Alternate theory.  After months of foreshadowing, PaceOptionalSummary
was exquisitely timed to coincide with last call.  Along with a
diversionary burst of fire concerning alleged process issues.

> Here's where SHOULD comes in. We're lucky that we have an example of
> what happens when a SHOULD is violated. I'm sure most of you saw the
> nasty arguments, accusations, and all-around busted software that
> happen this week with Google Web Accelerator and Ruby On Rails.[0]
> Ugly, right? This WG should be proud that we've kept the SHOULDs to a
> minimum.

Interesting analogy, let's see how it pans out.

The W3C could have made idempotency a MUST, which effectively would have
prevented useful things like hit counters.

Or they could have made idempotency a MAY, slamming the door shut not
only things like Google's WebAccelerator, but also on all web crawlers.

Instead, they decided to make idempotency a SHOULD, opening the door for
web crawlers by putting servers on notice that in the event of a
conflict, the onus is on them.

  - - -

Back to Atom.

If a entry in a feed does not include a title, and Firefox's Live
Bookmark support choses not to display it, who is the onus on?

If an entry in a feed contains neither a textual content nor a summary,
and Walter's search engine choses not to index it, who is the onus on?

Simply put, PaceOptionalSummary is incomplete.

>> their outcomes are so different?

In my note yesterday morning, I made it abundantly clear what I objected 
to.  It wasn't the text between the ==Proposal== and ==Impacts== markers.

  - - -

The W3C got it right.  And so should we.

Answer the two questions above.  Without hysterics like "burst into
fire".  What we actually are talking about here is aggregators that drop
information on the floor.

Should we warn producers about this?

- Sam Ruby

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 May 2005 15:25:12 +0200

> prevented useful things like hit counters.

Not true. Quoting RFC2616:

"In particular, the convention has been established that the GET and 
HEAD methods SHOULD NOT have the significance of taking an action other 
than retrieval. These methods ought to be considered "safe". This allows 
user agents to represent other methods, such as POST, PUT and DELETE, in 
a special way, so that the user is made aware of the fact that a 
possibly unsafe action is being requested.

Naturally, it is not possible to ensure that the server does not 
generate side-effects as a result of performing a GET request; in fact, 
some dynamic resources consider that a feature. The important 
distinction here is that the user did not request the side-effects, so 
therefore cannot be held accountable for them."

Best regards, Julian

---

From: Robert Sayre <[email-masked]>
Date: Tue, 10 May 2005 09:28:08 -0400

> Bookmark support choses not to display it, who is the onus on?

No one. The spec doesn't say anything about  what must be displayed.
 
> and Walter's search engine choses not to index it, who is the onus on?

No one. The spec doesn't say anything about  what must be persisted.

> Should we warn producers about this?

No. These are application-specific issues. Every application is different.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Tue, 10 May 2005 07:45:49 -0600

> them available, and aren't supplying atom:content?

Yes.

Note that I also recognize the legitimacy of publishing a feed without 
the summary, even if available, in some circumstances--hopefully in an 
alternative version of the feed (ie., hopefully there's a version of 
the feed with summaries or content, and a special-purpose one without). 
  That'd lead to a SHOULD, right?

---

From: Tim Bray <[email-masked]>
Date: Tue, 10 May 2005 07:31:26 -0700

> them available, and aren't supplying atom:content?

Yes, but I'd go further; I'd like to encourage, in general, producers 
to put more than less stuff in feeds, and provide a summary whenever 
they possibly can.

My only angst at this moment is whether the canonical SHOULD is the 
right tool to do that. -Tim

---

From: Robert Sayre <[email-masked]>
Date: Tue, 10 May 2005 10:37:25 -0400

> to put more than less stuff in feeds, and provide a summary whenever

Shouldn't we warn producers that this hurts performance in cellphones
and Firefox? ;)

Seriously, the benefits of providing the *right* amount of information
are extensive, but it's totally inappropriate to specify it.
 
> right tool to do that.

It definitely is not. Conformant Atom Processors MUST interoperate
with title-only feeds. That's not a big deal, because all of them do.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 10 May 2005 15:48:39 +0100

Tim Bray wrote:
> Yes, but I'd go further; I'd like to encourage, in general, producers to 
> put more than less stuff in feeds, and provide a summary whenever they 
> possibly can.

MAY is the requirement level I would choose for something like a 
summary, which isn't a control code or interoperability hotspot. My 
sense of things, based on the paces and discussion I've seen, is that 
MAY won't accord sufficient moral obligation to gain consensus here. 
Perhaps that can be offset by producing text that urges the publisher to 
consider emitting summaries.

cheers
Bill

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 10 May 2005 18:28:28 +0200

* Bill de hÓra <[email-masked]> [2005-05-10 17:00]:
> Perhaps that can be offset by producing text that urges the
> publisher to consider emitting summaries.

Maybe it’s something for the implemetor’s guide as opposed to the
spec, then?

Regards,
-- 
Aristotle

---

From: Robert Sayre <[email-masked]>
Date: Tue, 10 May 2005 12:33:42 -0400

> consider emitting summaries.

Or, we could figure out a way to let the client ask for the amount of
information it desires, rather than legislate morality.

http://www.franklinmint.fm/blog/archives/000381.html

After all, we're not having discussions on how many entries there
should be in a feed. The amount of work on content
negotiation/instance manipulation of feed resources should indicate
there is no right answer to these questions.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 10 May 2005 18:05:10 +0100

> Maybe it’s something for the implemetor’s guide as opposed to the

I raised that question already:

  http://www.mail-archive.com/[email-masked]/msg02809.html

the WG didn't discuss it in follow-up (I think).

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Tue, 10 May 2005 13:59:07 -0400

On 5/10/05, A. Pagaltzis <[email-masked]> wrote:
> Maybe it's something for the implemetor's guide as opposed to the
> spec, then?

That's one option. If the implementor's guide were a BCP RFC, it would
be easy to flag in a feed validator. The validator at
feedvalidator.org spits out a pretty scary warning when it decides to
warn (example: javascript in html content). Many people mistake the
warnings for an error, because the little 'valid' badge is buried
under the warning message and source code.

A BCP RFC could be used as fodder for a less-scary looking warning.
Something like "This feed may not follow established best practices".

Another option would be to give title-only entries an intimidating
name in the spec. Something like "Entries that lack both an
atom:summary and an atom:content are termed 'Content-Free'."

Or we could do both.

Robert Sayre