Subject: Re: Consensus call on last raft of issues

From: Robert Sayre <[email-masked]>
Date: Wed, 18 May 2005 13:03:03 -0400

I broadly agree with the chairs' opinions. 

> Tim Bray wrote:
>> 
>> 
>> PaceTextShouldBeProvided
>> 
>> +1 from Ruby, explicit -1's from Sayre and de hÓra.  However, taking 
>> this and PaceOptionalSummary together, it seems clear that the WG 
>> generally believes the following:
>> 
>> - Title-only feeds are OK for data where that's really all you have.
>> - Failing to provide summaries when they could potentially exist is 
>> regrettable and should be discouraged.
>> - There are certain classes of software which will not be able to make 
>> use of content-light feeds, for example full-text indexers.
>> - It is not acceptable for software to fail (note "fail", as opposed to 
>> "not make full use of") just because the summary is missing.

Missed one:
- There are many applications and users that *don't want* summaries.
Some examples include Firefox, Cellphones, Tivos, and whoever is
subscribing to JamesT's title-only feed.

This makes the second bullet point false. It is not regrettable to
provide applications with exactly what they need. However, I agree
that some education is in order.

>> 
>> There is lack of consensus in the WG as to whether RFC2119 "SHOULD" is 
>> an appropriate level of language to use in encouraging the provision of 
>> summaries.
>> 
>> Conclusion: This Pace is rejected.  However, the editors are directed to 
>> include the following text in 4.2.13:
>> 
>> "Experience teaches that feeds which contain textual content are in 
>> general more useful than those which do not.  

This statement seems overbroad to me, and doesn't directly speak to
the data format.

>> There are certain classes 
>> of application, for example full-text indexers, which will be unable to 
>> make effective use of entries which do not contain text in either 
>> atom:summary or atom:content.  

Walter mentioned that he wouldn't index them, but just skip through
them to the resources they're linking to. This is a title-only feed's
purpose in life, so it's probably not a good example. I think it would
be more productive to explain why one might want to omit a summary
(see below).

>> Feed producers should be aware of these 
>> issues and are encouraged to include a meaningful atom:summary in 
>> entries lacking atom:content wherever possible.  

See above.

>>However, the absence of 
>> atom:summary is not an error and software MUST NOT fail to function 
>> correctly as a consequence of such an absence."

We don't use the term 'software' in the draft. We discuss Atom
Processors. If we were to define Atom Processors in opposition to an
'application', as in PaceDefineAtomProcessor, we could say a lot about
applications. Note that one major goal of  PaceDefineAtomProcessor is
to avoid making normative requirements on applications.

-----
Some applications may choose to require a minimum amount of inline
text or (X)HTML data to function reliably and predictably. For that
reason, atom:entry elements are advised to contain a non-empty
atom:summary element when the entry contains no atom:content element.

The atom:summary element can be omitted if the Atom entry is generated
for an application with known requirements that make the inclusion of
an atom:summary element impractical (such as limited bandwidth).
However, when some general-purpose applications encounter such
entries, those entries might be ignored.

Regardless of how an associated application will handle entries with
no atom:summary element, all Atom Processors MUST NOT fail to process
Atom entries simply because they contain no atom:summary or
atom:content element.
----

Sam Ruby wrote:
> Much of the discussion of this pace centered around the proposed changes 
> to section 4.1.2.  However, there is more to this pace.

Sam, do you think any of your concerns could be incorporated into the
text above? If so, please make suggestions. If not, could you be more
specific about the parts of the Pace you feel were overlooked?

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Wed, 18 May 2005 10:40:19 -0700

On May 18, 2005, at 10:03 AM, Robert Sayre wrote:

> Processors.

Oops, editorial issue, please maintain consistency in the draft.

>  If we were to define Atom Processors in opposition to an

Yeah, in the case of XML, having the notion of an XML processor allowed 
us to describe some real important things that turned out to be hard to 
describe any other way.  My personal opinion is that the benefit of 
defining this in the Atom case does not justify the cost.   --Tim

---

From: Robert Sayre <[email-masked]>
Date: Wed, 18 May 2005 13:57:31 -0400

On 5/18/05, Tim Bray <[email-masked]> wrote: 
> defining this in the Atom case does not justify the cost.

What's the cost? Atom Processor is an undefined specification term,
and we need to define it. The fact that the spec has Atom Processors
'displaying' things is particularly bothersome to me. I found that
borrowing the idea of a processor in relation to an application
clarified a bunch of other issues. For example, "Atom Processors MAY
provide some or all of that markup to the application" accurately
describes the behavior of MarkP's parser.[0]

Robert Sayre

[0] http://www.feedparser.org/docs/html-sanitization.html

---

From: Robert Sayre <[email-masked]>
Date: Wed, 18 May 2005 14:03:19 -0400

On 5/18/05, Graham <[email-masked]> wrote:
> On 18 May 2005, at 6:03 pm, Robert Sayre wrote:
> 
> > Missed one:
> > Some examples include Firefox, Cellphones, Tivos
> 
> What happens when FireFox expands their Atom support to show
> summaries, but everyone's subscribed to title-only feeds?

Well, if they plan to expand support, they probably won't get in that
situation anyway. I've found they are more concerned about sucking
down huge full-content feeds and interupting the browser experience.
Of course, if someone figured out some content-negotation, they
wouldn't get themselves in either bind.

> And why
> wouldn't a TiVo or a cellphone want summaries? They have big screens
> and decent storage space, and the data transfer overhead is pretty
> negligible, and should be handled by a gateway if the pipe is that
> narrow.

Graham, I am not making this up. Review the list for posts on this
issue from people with email addresses that come from places like
Motorola and Nokia. RogerB specifically mentioned that TiVo users
squawked when he took away title-only feeds.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Wed, 18 May 2005 16:10:12 -0400

> specific about the parts of the Pace you feel were overlooked?

A concrete example of my concern is that feeds with atom:entries 
containing <atom:title/> will have those entries omitted by Firefox's 
livebookmark support.

The proposed changes to sections 3.1.1.1, 3.1.1.2, and 3.1.1.3, apply to 
all text constructs, not simply atom:summary.

All that needs to be done is to expand whatever wording we come up with 
to include title and content.

- Sam Ruby

---

From: Nikolas Coukouma <[email-masked]>
Date: Wed, 18 May 2005 16:14:01 -0400

Graham wrote:

> summaries, but everyone's subscribed to title-only feeds? And why 
> Graham

This is a bit nitpicky, but
* I doubt Firefox will ever support summaries in it's Live Bookmarks 
feature. It's intended for link (title-only) feeds, as the name 
suggests. There's a number of extensions that provide this 
functionality, but it seems Mozilla has opted to keep this in the mail 
component (Thunderbird)
* Cellphones (and PDAs, for that matter) don't have big screens or 
decent storage space.
* TiVo's have big screens, but the resolution sucks so you don't want to 
display anything in font size < 25pt.

The last two suggest that summaries should be very short (e.g. not a 
paragraph, but a sentence or two) more than they suggest no summary at all.

-Nikolas Coukouma

---

From: Robert Sayre <[email-masked]>
Date: Wed, 18 May 2005 16:36:07 -0400

> to include title and content.

How about this:

-----
Some applications may choose to require a minimum amount of inline
text or (X)HTML data to function reliably and predictably. For that
reason, atom:entry elements are advised to contain a non-empty
atom:title element, a non-empty atom:summary element when the entry
contains no atom:content element, and a non-empty atom:content element
when that element is present.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Wed, 18 May 2005 16:59:50 -0400

> when that element is present.

That works.  Thanks!

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Wed, 18 May 2005 22:05:37 +0100

On 18 May 2005, at 9:36 pm, Robert Sayre wrote:

> atom:entry elements are advised to contain ... a non-empty  
> atom:summary element when the entry
> contains no atom:content element

I'd like us to advise including an atom:summary when atom:content is  
binary (or for that matter, any non-text/html/xhtml type)

> entries, those entries might be ignored.

I like this.

> Atom entries simply because they contain no atom:summary or

Do we have a definition of "process" (and/or "fail")?

Graham

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 18 May 2005 23:20:00 +0200

* Graham <[email-masked]> [2005-05-18 23:15]:
>> Regardless of how an associated application will handle
>> entries with no atom:summary element, all Atom Processors MUST
>> NOT fail to process Atom entries simply because they contain
>> no atom:summary or atom:content element.
> 

I think the original intent of the previous discussion was to say
at this point that “an Atom Processor MUST NOT fail to process an
Atom feed with entries that lack an atom:summary or
atom:content,” as opposed to saying they “MUST NOT fail process
Atom entries […],” which is an entirely different kettle of fish.

In other words, it had been suggested that processors may freely
skip entries which they consider insufficiently rich, but they
may not refuse processing a feed that contains such entries.

Regards,
-- 
Aristotle

---

From: Graham <[email-masked]>
Date: Wed, 18 May 2005 18:49:39 +0100

Graham

---

From: Robert Sayre <[email-masked]>
Date: Wed, 18 May 2005 18:10:41 -0400

> binary (or for that matter, any non-text/html/xhtml type)

OK. We can do that by accounting for atom:content elements with media
types in @type.

-----
Some applications may choose to require a minimum amount of inline
text or (X)HTML data to function reliably and predictably. For that
reason, atom:entry elements are advised to contain a non-empty
atom:title element, a non-empty atom:content element
when that element is present, and a non-empty atom:summary element
when the entry
contains no atom:content element or the atom:content element's type is
a MIME media type.

 
> Do we have a definition of "process" (and/or "fail")?

Well, this text assumes something similar to this paragraph in
PaceDefineAtomProcessor:

   This specification describes conformance in terms of two artifacts;
   Atom Feed Documents and Atom Entry Documents. Additionally, it
   places some requirements on Atom Processors. An Atom Processor 
   is a software module used to read Atom Documents and provide 
   access to their content and structure. It is assumed that an Atom 
   Processor is doing its work on behalf of another module, called the 
   application. 

If we had text like that, it would be reasonable to assume that
'process' means 'provide access to their content and structure'. It
also be reasonable to assume that 'fail' means 'doesn't provide access
to their content and structure'.

Obviously, Tim is not a fan of that proposal. I think we should steal
from the best.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Wed, 18 May 2005 21:19:18 -0400

> contains no atom:content element or the atom:content element's type is

Isn't that redundant?  From PaceOptionalSummary:

       atom:entry elements MUST contain an atom:summary element in any of
       the following cases:
       *  the atom:entry contains an atom:content that has a "src"
          attribute (and is thus empty).
       *  the atom:entry contains content that is encoded in Base64; i.e.
          the "type" attribute of atom:content is a MIME media type
          [MIMEREG] and does not begin with "text/" nor end with "+xml".

- Sam Ruby

---

From: Tim Bray <[email-masked]>
Date: Wed, 18 May 2005 20:18:28 -0700

> Isn't that redundant?  From PaceOptionalSummary:

Yup.  Think we got that covered. -Tim

---

From: Sam Ruby <[email-masked]>
Date: Thu, 19 May 2005 06:32:27 -0400

> Yup.  Think we got that covered. -Tim

Off list, Robert pointed out to me that that the spec text I cited 
didn't cover empty summaries.  He's right.

- Sam Ruby

---

From: Isofarro <[email-masked]>
Date: Thu, 19 May 2005 18:31:30 +0100

> binary (or for that matter, any non-text/html/xhtml type)

+1 (From an accessibility perspective)

---

From: "Roger B." <[email-masked]>
Date: Thu, 19 May 2005 13:32:25 -0500

> RogerB specifically mentioned that TiVo users

Robert: Two things:

(1) By "TiVo users", I was referring to the folks inhabiting TiVo's
official message boards... my scraped, title-only feeds were better
suited for a high-traffic forum than the native feeds produced by
vBulletin or whatever they're using.

So just to clarify, I was *not* referring to apps running on a TiVo
box itself. The only non-hack RSS reader currently running on the TiVo
platform just uses a proxy to access Bloglines, and therefore doesn't
have any unique preference for or against summary-free feeds.

(2) I support the notion of an Atom Processor. Tim's proposed language
implies that dropping content-free entries on the floor is a failure
to function correctly, which is misleading. Defining the distinction
between "a thing that is looping over a series of XML entries to
extract data" and "a thing that is displaying, manipulating, or
otherwise making use of that data" would be useful.

--
Roger Benningfield

---

From: Tim Bray <[email-masked]>
Date: Thu, 19 May 2005 06:07:03 -0700

> when that element is present.

We observe that the paragraph above is getting support from the WG 
members who have been most engaged in this area of the discussion.

Rephrasing slightly because I don't believe that XML elements are very 
responsive to advice.  As an example freak, I'd also like to keep the 
concrete example of a full-text indexer from the consensus call.  Thus,

<co-chair-mode>
Paul and I consider that the following text has consensus support of 
the WG and the editors are directed to include it in the format draft 
(editorial judgment call on where to insert):

Some applications (one example is full-text indexers) require a minimum 
amount of text or (X)HTML to function reliably and predictably.  For 
that reason, it is advisable that each atom:entry element contain a 
non-empty atom:title element, a non-empty atom:summary element when the 
entry contains no atom:content element, and a non-empty atom:content 
element when that element is present.
</co-chair-mode>

  -Tim

---

From: Robert Sayre <[email-masked]>
Date: Thu, 19 May 2005 15:40:47 -0400

> element when that element is present.

Is this text intended to replace the paragraph the editors were
previously directed to insert?

Robert Sayre

---

From: Norman Walsh <[email-masked]>
Date: Thu, 19 May 2005 17:08:37 -0400

/ Tim Bray <[email-masked]> was heard to say:
| <co-chair-mode>
| Paul and I consider that the following text has consensus support of the WG
| and the editors are directed to include it in the format draft (editorial
| judgment call on where to insert):
|
| Some applications (one example is full-text indexers) require a minimum
| amount of text or (X)HTML to function reliably and predictably.  For that
| reason, it is advisable that each atom:entry element contain a non-empty
| atom:title element, a non-empty atom:summary element when the entry
| contains no atom:content element, and a non-empty atom:content element when
| that element is present.
| </co-chair-mode>

+1

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | The first step towards madness is to
http://nwalsh.com/            | think oneself wise.--Fernando De Rojas

---

From: "Roger B." <[email-masked]>
Date: Thu, 19 May 2005 16:48:50 -0500

> Rephrasing slightly...

+ 1

--
Roger Benningfield

---

From: Graham <[email-masked]>
Date: Fri, 20 May 2005 01:16:03 +0100

On 19 May 2005, at 2:07 pm, Tim Bray wrote:

> Some applications (one example is full-text indexers) require a  
> minimum amount of text or (X)HTML to function reliably and  
> predictably.  For that reason, it is advisable that each atom:entry  
> element contain a non-empty atom:title element, a non-empty  
> atom:summary element when the entry contains no atom:content  
> element, and a non-empty atom:content element when that element is  
> present.

I find the conflation of presence and emptiness a little opaque. I'd  
rather the text said that, in general, when any of these elements are  
present they shouldn't be empty. The other part of this text, that  
summary be present when content isn't, can then be separated out for  
the sake of clarity.

Otherwise, it's fine.

Graham

---

From: Tim Bray <[email-masked]>
Date: Fri, 20 May 2005 17:22:37 -0700

On May 19, 2005, at 12:40 PM, Robert Sayre wrote:

>> minimum

Nope, can't do that, because there's stuff in that paragraph that's not 
here.  Here's my best effort at combining the original consensus call 
with the above paragraph:

Experience teaches that feeds which contain textual content are in 
general more useful than those which do not.  Some applications (one 
example is full-text indexers) require a minimum amount of text or 
(X)HTML to function reliably and predictably.  Feed producers should be 
aware of these issues.  It is advisable that each atom:entry element 
contain a non-empty atom:title element, a non-empty atom:summary 
element when the entry contains no atom:content element, and a 
non-empty atom:content element when that element is present. However, 
the absence of atom:summary is not an error and Atom Processors MUST 
NOT fail to function correctly as a consequence of such an absence.

  -Tim