Subject: PaceCoConstraintsAreBad

From: Robert Sayre <[email-masked]>
Date: Wed, 06 Apr 2005 16:24:31 -0400

http://www.intertwingly.net/wiki/pie/PaceCoConstraintsAreBad

Abstract
------------------------
Require atom:id, atom:title, atom:updated, atom:author. That's it.

Status
------------------------
Open

Rationale
------------------------
The spec delivers value when it can make an element mandatory.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Wed, 06 Apr 2005 22:07:19 -0400

> http://www.intertwingly.net/wiki/pie/PaceCoConstraintsAreBad

co-constraints are bad.

Entries without either a summary or content or even a link to where you 
can find the data are worse.

-1

- Sam Ruby

P.S.  If it pleases your sense of aesthetics, merge these three elements 
into one mandatory element, with an attribute to specify whether the 
innerxml represents a summary or a content, and another optional element 
specifying the location.  Oh, and allow multiples of this element as 
there are scenarios in which both summaries and content are provided.

---

From: Robert Sayre <[email-masked]>
Date: Wed, 06 Apr 2005 22:10:47 -0400

> can find the data are worse.

Does my Pace allow such a creature?

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Wed, 06 Apr 2005 22:40:13 -0400

Robert Sayre wrote:
> Sam Ruby wrote:
> 
>> co-constraints are bad.
>>
>> Entries without either a summary or content or even a link to where 
>> you can find the data are worse.
> 

This pace dropped the requirement for an alternate link.  This pace 
dropped the requirement for a summary when content is not present. 
Content remains optional.

Am I misreading the Pace?  The abstract seems clear enough...

While I agree with your recent statement that "no one has spoken up in 
favor of the current text", I resonate more with Paul's recent 
statement[1] that:

   It doesn't matter whether or not they are "too controversial"; the
   spec is frozen for significant technical changes.

   Unless, of course, the WG decides we really do want to open it all up
   again an take another probably four months of deciding what else we
   want to add and change. We can do that by amending our charter. So
   far, I have not heard consensus going towards that, but I could be
   wrong.

I wrote a Pace that inserted seven words and only changed one element, 
feeling that we might be able to come to an agreement on that.  This 
appears to have been a tactical error as it was immediately followed by 
a pace that changed one word and added twenty one, affecting two 
elements.  Now you introduce a pace that changes the definition of three 
elements.

My order of preference:

   PaceFeedIdOrAlternate
   PaceFeedIdOrSelf
   Current Text
   PaceCoConstraintsAreBad

- Sam Ruby

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

---

From: Robert Sayre <[email-masked]>
Date: Wed, 06 Apr 2005 23:04:15 -0400

> dropped the requirement for a summary when content is not present. 

Yes, because the WG has *never* voiced an opinion in favor of that 
constraint, and we fail to meet the requirements of our charter for any 
definition of "syndication"that takes prior art into account.

> Content remains optional.

The pace did not drop the requirement for a link element in the absence 
of content.

> appears to have been a tactical error...

Strawmen are usually tactical errors.

>   PaceCoConstraintsAreBad

"no one has spoken up in favor of the current text" remains true.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Wed, 06 Apr 2005 20:30:37 -0700

On Apr 6, 2005, at 8:04 PM, Robert Sayre wrote:

> constraint,

You are incorrect.  There was an extended discussion, with Mark Pilgrim 
steadfastly refusing to let the hideous old multipart/alternate go 
until we had another proposal that had a good accessibility story.  
There was a Pace, I forget the name, that discarded 
multipart/alternative and suggested multiple changes, including the 
requirement that there be summary if there's no content, and it clearly 
got better-than-rough consensus.

> and we fail to meet the requirements of our charter for any definition 
> of "syndication"that takes prior art into account.

Huh?  The prior art was considered and the group decided to stiffen the 
historical rules; largely, as I said, in the interests of 
accessibility. -Tim

---

From: Robert Sayre <[email-masked]>
Date: Wed, 06 Apr 2005 23:45:58 -0400

Tim Bray wrote:
> steadfastly refusing to let the hideous old multipart/alternate go until 
> we had another proposal that had a good accessibility story. 

I'm very familiar with that discussion, because I am the one who took 
the time to work through it, by parrying something like 20 insults.

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

> There was 
> a Pace, I forget the name, that discarded multipart/alternative and 
> suggested multiple changes, including the requirement that there be 
> summary if there's no content, and it clearly got better-than-rough 
> consensus.

That would be http://www.intertwingly.net/wiki/pie/PaceReformedContent3.

The list traffic around that shows a clear lack of consensus on this 
very topic, with many folks making the never-explained assertion that an 
entry without content or summary is somehow less-accessible to some 
group of people.

> historical rules; largely, as I said, in the interests of accessibility. 

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Wed, 6 Apr 2005 22:23:48 -0600

>   PaceCoConstraintsAreBad
To summarize what elements would be required under each, all four 
require atom:title and atom:updated. Additionally:

Current Text: Requires atom:link[@rel="alternate"].
PaceFeedIdOrAlternate: Requires either atom:link[@rel="alternate"] or 
atom:id.
PaceFeedIdOrSelf: Requires either atom:link[@rel="self"] or atom:id.
PaceCoConstraintsAreBad: SHOULD have atom:link[@rel="alternate"]; 
Requires atom:id and atom:author? (the abstract says so, but the 
proposed text doesn't).

My preferences (which, below the first one, shifted as I typed my 
comments below--score one for "principled reasoning"):

PaceFeedIdOrSelf
PaceCoConstraintsAreBad
PaceFeedIdOrAlternate
Current Text

Comments:
* PaceFeedIdOrSelf: atom:id and atom:link[@rel="self"] are somewhat 
interchangable as feed identifiers.

* PaceCoConstraintsAreBad: less change at this point in time would be 
more comfortable, and I'm undecided about atom:author...which is okay, 
because the Pace is too ;^). But it's probably an improvement over the 
current situation.

* PaceFeedIdOrAlternate: atom:id and atom:link[@rel="alternate"] don't 
seem to me to fill similar enough roles to be alternative requirements, 
but at least atom:link[@rel="alternate"] wouldn't be absolutely required

* Current Text: Requiring atom:link[@rel="alternate"] just seems 
unnecessary, and is unreasonable in some cases

---

From: Robert Sayre <[email-masked]>
Date: Thu, 07 Apr 2005 09:10:14 -0400

Sam Ruby wrote:

> If, instead, it opens the door for multiple changes without explicit 
> rationale; at the last minute; overturning carefully formed consensus; 
> then it was not.

Uh, so your changes are ok, but mine aren't? We continue the lovely 
pattern of DOSing proposals.

> 
> I am willing to go with PaceFeedIdOrSelf. 

I'm not. link @rel="self" is just horrible, and invention anyway.

I guess the people who want to ditch the alternate will be making their 
case in Last Call.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Thu, 07 Apr 2005 09:33:12 -0400

> pattern of DOSing proposals.

Unfair.  I've withdrawn my proposal.

At this point, small surgical changes to address specific concerns may 
(or may not) be acceptable.  Wholesale changes with little rationale are 
less likely to be so.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Thu, 07 Apr 2005 09:49:38 -0400

> (or may not) be acceptable.  Wholesale changes with little rationale are 

Well, who really cares anyway. I'll get the draft ready. Nobody propose 
any 'wholesale changes' in the meantime, OK?

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Thu, 07 Apr 2005 08:35:03 -0400

> The pace did not drop the requirement for a link element in the absence 

OK, I missed that.  What else did I miss at this late date?

As it stands, this Pace declares co-constraints bad, selectively removes 
a few co-constraints, and leaves others, with little rhyme or reason.

> Strawmen are usually tactical errors.

It was a serious proposal.  And if it results in a clear consensus 
around PaceFeedIdOrSelf, then it was useful.

> "no one has spoken up in favor of the current text" remains true.

I am willing to go with PaceFeedIdOrSelf.  A number of people have 
expressed support for it.  I don't know if it meets a threshold or not - 
at the moment the bar is pretty high.  And the number of active 
proposals is troublesome.

I've marked PaceIdOrAlternate withdrawn.

I remain -1 on PaceCoConstraintsAreBad.

- Sam Ruby

---

From: Tim Bray <[email-masked]>
Date: Thu, 07 Apr 2005 09:50:16 -0700

On Apr 6, 2005, at 8:45 PM, Robert Sayre wrote:

>> You are incorrect.  There was an extended discussion, with Mark 
>> Pilgrim steadfastly refusing to let the hideous old 
>> multipart/alternate go until we had another proposal that had a good 
>> accessibility story.
>

I'm sorry; Paul and I waded through the WG email in detail and issued a 
detailed consensus call and got no significant push-back and the 
results went into the draft.

> very topic, with many folks making the never-explained assertion that 
> an entry without content or summary is somehow less-accessible to some 
> group of people.

Actually, the argument was that if the content is either non-textual or 
remote, a summary is beneficial to accessibility.  I agree that many 
people made this argument, sufficient in the co-chairs' minds to 
establish rough consensus.

A flurry of Paces has been filed.  That's good.  In my opinion, none of 
them are very material to the kind of content we're seeking from the 
broader IETF community, and it is appropriate at this time to seek that 
commentary with the draft we have now (modulo our AD's issues), which I 
have no problem in asserting enjoys rough-consensus support.  Once that 
has launched, we'll figure out an orderly way to set up a discussion on 
the Paces from the last week.  -Tim

---

From: Robert Sayre <[email-masked]>
Date: Thu, 07 Apr 2005 13:03:50 -0400

> establish rough consensus.

I understand the argument if the content is non-textual, sort of. For 
example, the thoroughly-vetted SVG format has no required metadata 
fields. Perhaps it would be a good idea to have an accessibility expert 
review the document and identify requirements that ensure accessibility. 
I asked back at the time. No one answered, but they did mention 
"screwing blind people" or something like that. Until it is reviewed, I 
consider those requirements a bug.

> broader IETF community...

Fully agree.

> Once that 
> the Paces from the last week.  

OK.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Thu, 07 Apr 2005 17:09:25 -0400

Robert Sayre wrote:
>> (or may not) be acceptable.  Wholesale changes with little rationale 
>> are less likely to be so.
> 

I don't know about you, but I do care.

Whether it is for accessibility, or for general usability, I want to 
ensure that every entry has a textual, non-remote component to it.

You have made a number of noises that it is your intent to use last call 
as your opportunity to challenge the working group to revisit this.

Please don't.

If you truly are concerned about co-occurrence constraints, recast the 
grammar so that content and summary are the same element, possibly with 
multipart alternatives.  See if you can come up with a less hideous 
syntax than either 0.3 or -07.  Make this element mandatory, and I'm happy.

If your real goal, however, is to make textual non-remote information 
optional, please don't.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Thu, 07 Apr 2005 17:22:17 -0400

> ensure that every entry has a textual, non-remote component to it.

Yeah, but we can't really legislate that, can we? We are making 
editorial decisions for publishers via validity constraints.

> as your opportunity to challenge the working group to revisit this.

You are implying that would be somehow inappropriate or unsportsmanlike. 
It isn't. If there is consensus, such a challenge would be squashed 
rather quickly, don't you think?

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Thu, 07 Apr 2005 14:54:01 -0700

> editorial decisions for publishers via validity constraints.

The line between "editorial decisions" and "technical constraints" is 
at best fuzzy.  We are entirely within our rights as a WG to write a 
spec that requires the presence of certain elements.

>> You have made a number of noises that it is your intent to use last 
>> call as your opportunity to challenge the working group to revisit 
>> this.
>> Please don't.
>
> You are implying that would be somehow inappropriate or 
> unsportsmanlike. It isn't. If there is consensus, such a challenge 
> would be squashed rather quickly, don't you think?

Just for the record, I strongly agree that Atom entries should be 
required to include (to use Sam's words) a textual non-remote 
component.  -Tim

---

From: Dan Brickley <[email-masked]>
Date: Thu, 7 Apr 2005 17:57:20 -0400

* Robert Sayre <[email-masked]> [2005-04-07 17:22-0400]
> >ensure that every entry has a textual, non-remote component to it.

+1
 
> editorial decisions for publishers via validity constraints.

This sounds roughly the same as requiring <title> in HTML, eg.
http://www.w3.org/TR/html4/struct/global.html#h-7.4.2 in that you 
can force documents to have some kind of title, but you can't 
legislate them into having sensible, accurate, etc titles. The schema 
can nudge people in the right direction though...

Dan

---

From: Robert Sayre <[email-masked]>
Date: Thu, 07 Apr 2005 17:59:40 -0400

> can nudge people in the right direction though...

Your example is roughly the same as requiring <atom:title>, which we do.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Fri, 08 Apr 2005 01:33:20 -0400

Tim Bray wrote:

> component.

In the words of your co-chair, this isn't a negotiating game.

Accessibility is a non-starter absent expert opinion or substantially 
similar formats. Frankly, the notion that remote content constitutes an 
accessibility concern is absurd. Might as well write off the whole Web.

What harm is our use of RFC2119 imperatives trying to prevent? Applying 
Dan Gillmor's definition of stupid[0] is a textbook case of trying "to 
impose a particular method on implementors".

Robert Sayre

[0] http://www.imc.org/atom-protocol/mail-archive/msg00555.html

---

From: "Laurent Le Meur" <[email-masked]>
Date: Fri, 8 Apr 2005 10:57:56 +0200

XML for News - Everything You Always Wanted to Know but Were Afraid to Ask.

Get the answers at the News Standards Summit on May 24 in Amsterdam:
   http://www.newssummit.org/2005/

Note: Includes a session on Atom and RSS developments. 

Laurent Le Meur
AFP - Head of Medialab
IPTC News Architecture WP chair

=================
Press release
=================

IPTC: Announcing the Second International News Standards Summit

Leaders in News Standards Development and Implementations to Meet in
Amsterdam

Windsor, England - 6 April 2005 - The International Press Telecommunications
Council IPTC, today announced that they are proud to co-sponsor the second
international News Standards Summit to be held on May 24, 2005 in
conjunction with the IDEAlliance XTech 2005 Conference at the Amsterdam RAI
Centre, the Netherlands. The Summit is a collaborative effort of
organizations committed to open standards development. Sponsors include IPTC
(http://www.iptc.org), G- SAM (http://www.g-sam.org), IDEAlliance
(http://www.idealliance.org), and Ifra (http://www.ifra.com).

The News Standards Summit will bring together major players--experts on news
metadata standards as well as commercial news providers, users, and
aggregators. As interest builds for standardizing news dissemination,
concern also grows that specifications are being developed in isolation.
How can the standards fit together? Where/how will standards converge? How
can the industry collaborate to identify gaps and overlaps and ensure their
systems will be able to interoperate now and in the future?
Together, participants will analyze the current state and future
expectations for news and publishing XML efforts from both the content and
processing model perspectives. The goal of the summit is to increase
understanding about the state of news standards, to highlight
standards-based implementation and to drive practical, productive
convergence. 

The program will feature presentations from the key news standards efforts
balanced by an implementation status report from a panel of international
users. The day will conclude with an open session where productive ideas for
moving forward will be proposed. Networking with others in the News Industry
is a key component of the Summit.  All program and registration
information is available at http://www.newssummit.org/   Those who attend
the summit will be given a discount on registration for the XTech 2005
Conference. (http://www.xtech-conference.org/2005/registration.asp )

About the IPTC
The IPTC, International Press Telecommunications Council, is a
not-for-profit consortium of the world's major news agencies, news
publishers and news industry system vendors based in Windsor, England. It
develops and maintains technical standards that are used by virtually every
major news organisation in the world. These standards cover news exchange
formats like IPTC7901, IIM, NITF, NewsML and SportsML, metadata container
schemas like the "IPTC Core" as well as metadata taxonomies like the Subject
NewsCodes. Find more about the IPTC at http://www.iptc.org 

About G-SAM
G-SAM is a not for profit professional Trade Association, which exists to
promote the development and adoption of technologies to manage, protect and
create value from digital assets. The group promotes integrated products and
processes that support interoperability and open standards that will drive
adoption and user acceptance of digital asset management
(DAM) and related technologies with over 200 corporate members worldwide.
Principal Founding Members of G-SAM are Avid Technology (NYSE: AVID), IBM
(NYSE: IBM), Ascent Media (NYSE:L), Artesia Technologies, Sony (NYSE: SNE)
and WAM!NET, a division of SAVVIS Communications (SVVS), Harris Corporation
(NYSE:HRS), and Quark. For more information, please visit
http://www.gsam.org.

About IDEAlliance
IDEAlliance (International Digital Enterprise Alliance) is a not-for-profit
membership organization advancing user-driven, cross-industry solutions for
all publishing and content-related processes by developing standards,
fostering business alliances, and identifying best practices. IDEAlliance
has been a leader in information technology - developing Document Markup
Metalanguage (GENCODE), sponsoring the development of Standard Generalized
Markup Language (SGML), and fostering eXtensible Markup Language (XML).
IDEAlliance builds on these languages to create specifications including
Publishing Requirements for Industry Standard Metadata (PRISM), Digital
Image Submission Criteria (DISC) and Information and Content Exchange (ICE)
that enhance efficiency and speed information in all aspects of publishing
and content-related processes.
Learn more about IDEAlliance at www.idealliance.org.

About IFRA
Ifra, the world's leading association for media publishing, is a service
organisation dedicated to the publishing industry worldwide.  More than 2000
publishing companies and suppliers to the publishing industry are currently
Ifra members.  Ifra is their forum to exchange experiences and to learn from
one another.  Ifra's name originates from "INCA-FIEJ Research Association",
whereby "INCA" stands for "International Newspaper Colour Association" and
"FIEJ" stands for "Fédération Internationale des Editeurs de Journaux".
Today the name "Ifra" stands by itself.

About XTech
XTech is a key forum for the web, XML, and open standards worlds. 
Formerly known as the XML Europe Conference, XTech has widened its scope to
incorporate neighbouring technologies from the web and business. As well as
XML, XTech 2005 will cover web development, browsers, open data, the
semantic web and more.

-
This e-mail, and any file transmitted with it, is confidential and  intended solely for the use of the individual or entity to whom it is addressed. If you have received this email in error, please  contact the sender and delete the email from your system. If you are  not the named addressee you should not disseminate, distribute or copy  this email.

For more information on Agence France-Presse, please visit our web site at http://www.afp.com

-

---

From: Walter Underwood <[email-masked]>
Date: Fri, 08 Apr 2005 15:56:48 -0700

> accessibility concern is absurd. Might as well write off the whole Web.

No, non-accessible designs are non-starters.

I am mystified when I see non-accessible web sites and technologies
deployed. If a building was build with round doorknobs and steps,
the architect would not get paid until it was fixed and made accessible.
Why is discrimination OK on the web?

Accessibility is required by law, and not just in the US. Plus, it is
an "essential aspect" of the web.

  "The power of the Web is in its universality. Access by everyone
   regardless of disability is an essential aspect."
      -- Tim Berners-Lee
  <http://www.w3.org/WAI/>

Is that expert enough for you?

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Robert Sayre <[email-masked]>
Date: Fri, 08 Apr 2005 18:59:47 -0400

> No, non-accessible designs are non-starters.

...

> Is that expert enough for you?

Walter, you are missing my point. You've said it yourself:

"Maybe summaries are optional, but not because accessibility is 
optional."[0]

Robert Sayre

[0] http://www.imc.org/atom-syntax/mail-archive/msg13600.html

---

From: Walter Underwood <[email-masked]>
Date: Fri, 08 Apr 2005 17:17:12 -0700

--On April 8, 2005 6:59:47 PM -0400 Robert Sayre <[email-masked]> wrote:
> "Maybe summaries are optional, but not because accessibility is optional."[0]

That was in reply to a proposal to make accessibility an optional profile, and
to make summaries required only in that profile. That approach is unacceptable.
I would read my comment as "regardless of your position on summaries, accessibility
is required."

Local textual summaries are rather common on the web. The <a> tag, for example.
Current accessibility practice is to make the anchor text understandable out
of context. In other words, to make it a summary of the linked resource.
Even if the remote resource is text!

For the <img> tag, the alt tag is used to provide a local, textual equivalent.
Again, this is required practice for accessibility. Same thing for graphs,
charts, audio, and video.

These are top-level requirements. They fit on the WAI pocket card. There
are ten "quick tips" and five of them are about local textual equivalents:

  <http://www.w3.org/WAI/References/QuickTips/>

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Robert Sayre <[email-masked]>
Date: Fri, 08 Apr 2005 20:29:52 -0400

> are ten "quick tips" and five of them are about local textual equivalents:

An Atom Entry without <content> or <summary> still has a <title>. Even 
more precisely, the link element contains a 'title' attribute. There's 
two local summaries for you. As I've pointed out already, none of the 
most current W3C formats *require* textual metadata, from a schematic 
perspective. This is because accessibility is a social issue, rather 
than an interop issue.

Insisting that constraint in the schema is there for accessibility's 
sake without explaining the *exact* reason is at best doing 
accessibility a disservice.

I want the to know the precise technical reason for these requirements. 
No one has given one. We all agree that accessibility is important. 
Please don't respond to me by saying that accessibility is important.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Sat, 09 Apr 2005 16:13:04 -0400

> 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.  In your zeal to filibuster on this particular topic, you 
have made a number of fallacious and personal attacks.

  - - -

 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.

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.

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.

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?

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".

More succinctly: if people today view how a given aggregator as feeds 
without descriptions as a bug to be fixed, 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.

  - - -

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?

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Sat, 09 Apr 2005 18:46:55 -0400

Sam Ruby wrote:
> 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 

You and others have made a number of rather unproductive comments as 
well. At least we can actually discuss the issue now.

> seen, entries have a summary or content.

Given the content of this list, that's not surprising.

> When I point that out, you take the opportunity to initiate an 

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

> 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.

> indicates that content can't be of zero length.  Is that sufficient for 

No. I think there's a difference between those two concepts.

http://www.imc.org/atom-protocol/mail-archive/msg00756.html

> 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?

> 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 

There's a difference between buggy and unsatisfying.

> providing a zero length content, but the outright omission of same - 

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

---

From: "Roger B." <[email-masked]>
Date: Sat, 9 Apr 2005 17:48:45 -0500

> clear response by the consuming public.

Sam: In the case of the no-content feeds I've produced over the last
few years, the response from the public has been "please keep them
coming". The folks in the Tivocommunity forum want me to bring my
scraped, title-only feeds back online because the recently added,
native forum feeds are kinda useless.

That said, I would have no problem at all with providing an empty
content element in such a feed, and I'm sure most aggregators would
handle it the same way they handle description-free RSS feeds.

Of course, cruft doesn't scare me the way it does some folks.

--
Roger Benningfield
http://admin.support.journurl.com/

---

From: Sam Ruby <[email-masked]>
Date: Sat, 09 Apr 2005 19:23:12 -0400

> handle it the same way they handle description-free RSS feeds.

Hi Roger!  Yes, I recall you constructively participating in when this 
was discussed previously, and consensus was declared on the issue by the 
co-chairs:

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

Permit me to quote you:

> My no-content feeds are distributing such limited info
> that there's really no need for anything more than RSS. Trying to force that
> kind of thing to work with Atom nets the user nothing (the RSS and Atom
> versions would be effectively identical), and blunts Atom's purpose (clearer
> specification) in the process. 

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Sun, 10 Apr 2005 00:26:21 +0100

No one agrees with you Robert. Quit it.

Graham

---

From: Walter Underwood <[email-masked]>
Date: Sat, 09 Apr 2005 16:35:33 -0700

> Please don't respond to me by saying that accessibility is important.

I would never say that. Required or essential, but not merely important.

wunder

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 10 Apr 2005 00:45:20 +0100

> No one agrees with you Robert. Quit it.

I suppose then I should state I'm very close to +1 on Robert's position.

I think this is an important discussion, insofar as whether the link or 
the content is primary stuff, and I wouldn't to see it cut short because 
it became another syndication row.

I'm trying to figure out what the problem with optional content is and I 
  can't see it. if I have a link/id for something and a bag of metadata 
related to that link I don't have to have a content blob for that to be 
useful or interoperable.

In particular the accessibility argument hasn't work for me (I have 
formal design/human-factors training and practice under my belt, but I'm 
not claiming to be an accessibility expert viz the Web).

cheers
Bill

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 10 Apr 2005 02:27:12 +0200

* Sam Ruby <[email-masked]> [2005-04-09 22:30]:
> 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?

I have no opinion either way (not that it would have much
weight), but I’m curious to know: why are atom:title and
atom:link/@title not sufficient a textual non-remote content?

Regards,
-- 
Aristotle

---

From: Tim Bray <[email-masked]>
Date: Sat, 09 Apr 2005 17:51:50 -0700

> No one agrees with you Robert. Quit it.

Well, Robert has not actually favored us with a single clear sentence 
expressing his point, so I'll try:

"The requirement on accessibility grounds for a required <atom:summary> 
is superfluous, because we have <atom:title> and one required text 
field is enough."

On balance, I would still lean to encouraging the use of <summary/> 
because I do feel that content-ful feeds are intrinsincally better than 
link feeds; but only really at a +/- 0 level.  That is to say, Rob's 
position is not that radical or unreasonable.  On the other hand, I 
tend to agree with Sam on the subject of Rob's rhetorical techniques.  
At the moment, my best judgment of rough consensus would read that most 
people want to retain the <atom:summary> requirement, but it's clearly 
not the case that no one agrees with Robert. -Tim

---

From: Graham <[email-masked]>
Date: Sun, 10 Apr 2005 02:11:39 +0100

> "The requirement on accessibility grounds for a required 
> <atom:summary> is superfluous, because we have <atom:title> and one 
> required text field is enough."

There's another solution compatible with this, which is to make title 
optional (which I've always supported). In most "title only" feeds, the 
title is usually wordy enough to make better sense as a summary or 
content.

(I'm still very concerned about dealing with the synthenic titles that 
will be unleashed by Atom in its current state)

Graham

---

From: Robert Sayre <[email-masked]>
Date: Sat, 09 Apr 2005 23:06:00 -0400

> expressing his point, so I'll try:

The 10th bullet point of section 4.1.2 should read:

atom:entry elements MUST contain an atom:summary element in either 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
       [RFC2045] and does not begin with "text/" nor end with "+xml".

> is superfluous, because we have <atom:title> and one required text field 
> is enough."
 >
> link feeds; but only really at a +/- 0 level.

Are legions of people complaining about del.icio.us and craigslist? 
Should we use our spec to imply publishers must provide text?

An app would handle an empty content element the same way it would an 
absent one. Thus, the current spec is concerned with advocacy, not interop.

> That is to say, Rob's 
> position is not that radical or unreasonable.  On the other hand, I tend 
> to agree with Sam on the subject of Rob's rhetorical techniques.  

Yes, well, what did it take to get the subject addressed in a technical 
manner? I've tried a variety of rhetorical techniques.

> At the 
> moment, my best judgment of rough consensus would read that most people 
> want to retain the <atom:summary> requirement, but it's clearly not the 
> case that no one agrees with Robert.

RFC 2822:                                Optional body
RSS 0.90: Required title, Required link, No       description
RSS 0.91: Required title, Required link, Optional description
RSS 0.92: Optional title, Optional link, Optional description
RSS 1.0:  Required title, Required link, Optional description
RSS 2.0:  Optional title, Optional link, Optional description
Atom 0.3: Required title, Required link, Optional summary and content

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Sat, 09 Apr 2005 23:42:35 -0400

> was discussed previously, and consensus was declared on the issue by the 

Ah, a process argument. If the chairs consider this discussion out of 
order, they can declare it so. I will respect that.

>> specification) in the process. 

That's not really true, isn't it? You see, an Atom feed would be 
required to have an id, a date, a link, and a title. Which RSS dialect 
can say that?

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Sun, 10 Apr 2005 14:52:34 +1000

On 10/4/05 1:06 PM, "Robert Sayre" <[email-masked]> wrote:

> absent one.

would it?

could it be reasonable that an empty element gets displayed as empty, but an
absent element triggers a fall back mechanism (eg. use the <summary>
element, and if that is missing display the <link rel=alternate> resource?

e.

---

From: James Tauber <[email-masked]>
Date: Sun, 10 Apr 2005 02:26:32 -0400

> element, and if that is missing display the <link rel=alternate> resource?

The first RSS Reader I used (SharpReader) would retrieve the linked resource
and display that in the absence of content (and presumably of summary too if
that distinction had been made at the time).

I enjoyed reading that way and so, as a result, the first feed I offered for
my own blog was a titles-only feed.

While I have long since added a full-content feed, I continue to get new
subscribers to the titles-only feed.

James
-- 
James Tauber         http://jtauber.com/
journeyman of some   http://jtauber.com/blog/

---

From: James Aylett <[email-masked]>
Date: Sun, 10 Apr 2005 10:38:56 +0100

On Sat, Apr 09, 2005 at 11:06:00PM -0400, Robert Sayre wrote:

[Text proposal]
>     * the atom:entry contains an atom:content that has a "src" attribute

FWIW, for clarity I would favour:

'... has a "src" attribute (and is thus itself empty).'

The 'itself' I feel allows the 'empty' assertion to govern
atom:content, not the src attribute, without ambiguity.

(Overall I'm neutral on this discussion, but I'd like the wording
clear whatever is chosen :-)

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  [email-masked]                               uncertaintydivision.org

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 10 Apr 2005 12:40:25 +0200

* James Aylett <[email-masked]> [2005-04-10 11:55]:
> > * the atom:entry contains an atom:content that has a "src"
> >   attribute (and is thus empty).
> 

To me that actually sounds even more ambiguous. I suggest simply
omitting the parentheses, which would seem to let the “and” more
clearly qualify the “that,” to my mind.

Regards,
-- 
Aristotle