Sam Ruby wrote:
Robert Sayre wrote:
I want the to know the precise technical reason for these requirements.
First, I'd like to ask a favor. Please wait 24 hours before replying to this email.
No.
In your zeal to filibuster on this particular topic,
Filibuster? What am I trying to delay? I've been trying to discuss this issue, and you've been throwing process objections back at me for weeks.
you have made a number of fallacious and personal attacks.
You and others have made a number of rather unproductive comments as well. At least we can actually discuss the issue now.
From my point of view, we are approaching the problem from different ends. I am asking "why?", and you are asking "why not?".
I want predictability. I want a lack of surprises.
You apparently want generality.
If in the first 18 months of this email list, there were no messages to this list with a zero length body. In 99.9999% of the feeds I have seen, entries have a summary or content.
Given the content of this list, that's not surprising.
The few cases I have seen where there have been feeds which (briefly) have not had so much as a summary, there always has been a swift and clear response by the consuming public.
When I point that out, you take the opportunity to initiate an ad-hominen attack.
By pointing to your email with the Gillmor quote? Perhaps you don't understand that answering this email
http://www.imc.org/atom-protocol/mail-archive/msg00554.html
with this
http://www.imc.org/atom-protocol/mail-archive/msg00555.html
is obnoxious. So yeah, you're going to get a response that's about you, rather than the issue at hand.
Besides, you're wrong.
http://*.craigslist.org/*.rss http://memepool.com/memepool.rss http://del.icio.us/rss/tag/atom http://finance.yahoo.com/rss/headline?s=yhoo,goog http://moto.debian.org.tw/rss.php?mode=simple http://www.daypop.com/top/rss.xml http://opensearch.a9.com/spec/opensearchrss/1.0/ http://lists.rootsecure.net/feed/?l=bugtraq&uid=xfuojrfvse http://xanadb.com/rss-lite.xml http://www.intertwingly.net/blog/2004/06/03/Aggregator-utf-16-tests.atom http://newsroom.cisco.com/data/syndication/rss2/news_at_cisco_10nr.xml http://www.apple.com/main/rss/hotnews/pr.rss http://fox.wikis.com/wc.dll?Wiki~WikiRss&details=1 http://feeds.smh.com.au/rssheadlines/top.rss http://www.artsjournal.com/beatrix/rss.xml http://www.drudgereportarchives.com/rss/recap.xml
"'dive into mark' publishes 2 feeds, one which contains only titles and one which contains the full text."
--http://inessential.com/?comments=1&postid=2057
I would like to see a feed format in which conformance is not defined by mob justice, but instead (as much as humanly possible) can be determined by a dispassionate RNG schema and/or feedvalidator.
Also note that I said "messages to the list with a zero length body". I did not say "messages without a body". I am not an expert on SMTP, but don't believe it is possible to have an email message without a body... the closest one can come is to have a message with a zero length body.
I dunno about SMTP either, but I can look at the IMF spec.
from RFC2822, Section 3.5, Overall message syntax:
message = (fields / obs-fields)
[CRLF body]the body and one of those infamous blank lines are optional.
Correct me if I am wrong, but I don't see anything in the spec that indicates that content can't be of zero length. Is that sufficient for your needs?
No. I think there's a difference between those two concepts.
http://www.imc.org/atom-protocol/mail-archive/msg00756.html
Finally, I remember the day when links disappeared from all Radio Userland feeds, to be replaced by guids. A core element replaced by another core element. As links were optional, there wasn't much anybody could say about this. I don't want this to happen to Atom. I want an aggregator author to be able to respond to "but why didn't you display my content" by pointing to an empty content (or summary) element and saying "I displayed what you told me to".
How does a co-constraint solve this problem? When that publisher says "why didn't you display my content?", what are they pointing at? An extension element? Why can't the aggregator author just point at the lack of a summary or content element?
Secondly, are publishers allowed to complain if an aggregator doesn't show an empty content pane?
More succinctly: if people today view how a given aggregator as feeds without descriptions as a bug to be fixed,
I don't think they do. When the feed is coming from a news site, they might, because they know it would be better like with content. But it's really an editorial issue, you know?
then one should either be able to identify one of the following as buggy: the feed, the aggregator, or the format itself. If the answer to this question is indeterminant, then interoperability suffers.
There's a difference between buggy and unsatisfying.
I realize that none of these arguments are foolproof. Exceptions can be found. But I will assert that the cumulative effect of each of these arguments is compelling enough to me to rise to the level where I feel a question of "why?" is warranted. Why? What compelling use case would enabling the omission of non-remote, textual content - i.e., not merely providing a zero length content, but the outright omission of same - enable?
Precise expression in things like the Atom protocol, del.icio.us, daypop, and HTTPLR. Remember how Anil Dash's linkblog had a summary element with just a URI in it, and RSS Bandit showed the web page instead? I feel that this restriction is going to create interop problems of that sort.
Robert Sayre
