Robert Sayre wrote:
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?
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
