Subject: Re: Last Call: required summary or content?

From: Robert Sayre <[email-masked]>
Date: Wed, 11 May 2005 13:59:58 -0400

There's one more issue that I would like to make the IESG aware of
before it evaluates the Atom Syndication Format. I don't believe the
format satisfies the Atompub charter:

   The format must be able to represent:
    * a resource that is a Weblog entry or article (e.g., it has
        an author, date, identifier, and content)
    * a feed or channel of entries, with or without enclosed
        content
    * a complete archive of all entries in a feed
    * existing well-formed XML (especially XHTML) content
    * additional information in an user-extensible manner

The current draft fails to satisfy the second bullet point.

Robert Sayre

P.S. -- Here are a couple of messages underscoring that atom:summary
and atom:content both serve as "enclosed content".

Tim Bray: http://www.imc.org/atom-syntax/mail-archive/msg14155.html
Sam Ruby: http://www.imc.org/atom-syntax/mail-archive/msg14057.html

On 4/25/05, Sam Ruby <[email-masked]> wrote:
> 
> Robert Sayre wrote:
> >
> >> * What the specification does currently
> >
> > In an Atom Entry, the specification currently requires a minimum set of
> > elements: <title>, <id>, and <updated>. Typically, there will also be a
> > <link> element. The specification includes a provision that allows its
> > omission on the condition that there is a <content> element. In addition
> > to that, the specification requires that either <summary> or <content>
> > be present.
> >
> >> * What you would like it to do instead
> >
> > I want to allow the metadata-only feeds allowed by all flavors of RSS,
> > and the omission of the <content> and <summary>. Such feeds are commonly
> > termed "title-only feeds", because that is all that is visible to the
> > user (the title is usually hyperlinked w/ the link element).
> 
> I will again point out that the current format allows for empty summary
> and/or content elements.
> 
> I have seen errors that the requirement for the inclusion of such
> elements would have prevented.
> 
> I have seen no arguments as to why placing such empty elements would
> impose an unreasonable burden on implementers.
> 
> - Sam Ruby
> 
>

---

From: Graham <[email-masked]>
Date: Wed, 11 May 2005 19:12:36 +0100

On 11 May 2005, at 6:59 pm, Robert Sayre wrote:

> before it eval.. (etc)

Can you please do something constructive and suggest language you'd  
find acceptable, and y'know, help reach consensus?

Graham

---

From: Robert Sayre <[email-masked]>
Date: Wed, 11 May 2005 17:58:37 -0400

> find acceptable, and y'know, help reach consensus?

I made a couple of suggestions here:
http://www.imc.org/atom-syntax/mail-archive/msg15086.html

I don't know what your goal is, so I'm just throwing things out there
to see if they're what you want. Please explain your problems with
each option, and I will try to work with you. Please note that the
interests of other implementors and users may not line up with yours.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Thu, 12 May 2005 00:11:01 +0100

> interests of other implementors and users may not line up with yours.

The "Implementor's Guide" may or may not ever exist and may or may  
not be read by anyone, so that isn't an option. Myself and Sam, and  
(I think) Tim and Antone, would all like the actual spec to make an  
actual recommendation that entries without enclosed content include a  
textual summary, if at all possible. Note no one wants to ban title- 
only feeds if they come from title-only resources. What language  
would you find acceptable that covers these bases?

Graham

---

From: Robert Sayre <[email-masked]>
Date: Wed, 11 May 2005 20:09:50 -0400

On 5/11/05, Graham <[email-masked]> wrote:
> not be read by anyone, so that isn't an option. 

Would you like to rephrase that as "I am concerned that the
implementor's Guide will never happen."? My honest impression is that
it will be far more popular than the spec itself, since the spec is
minimal and abrasive. The style of the document makes sections that
don't have specification words stick out like a sore thumb. I think I
understand the conflict.

> Myself and Sam, and

I am asking you to detail the operational result you are after. You
are telling me what you want the spec to say. This is not productive.
I also made two suggestions in the email I pointed you to, but you
responded to only one.

> textual summary, if at all possible.

Careful rhetoric proposing a different, and very strained,
interpretation of our charter is not going to fool me. This is the
kind of thing that makes negotiation unworthwhile. The charter is on
my side. Live with it. I am not especially fond of making the
argument, but it becomes necessary if people make scope arguments.

> Note no one wants to ban title-
> only feeds if they come from title-only resources. 

This is the problem I have. Title-only feeds are perfectly ok from any
resource. They are probably not a good idea as the only possibility
available from a blog or news site, but it's really all semantics and
judgement calls. Judgement calls for the publisher to make, based on
the type of application and users they are targetting. The whole point
of HTTP is to allow servers to represent resources in the amount of
detail they see fit.

Unfortunately, RFC2119 is not perfect. It contains no specification
word that would allow a validator to emit a warning while
simultaneously requiring support for title-only feeds. SHOULD would
also tar title-only feeds as bad practice. They aren't.

If the Implementor's Guide existed and were widely read, would it be
the right place for this encouragement? I think it would be. In my
opinion, this is advocacy. I happen to agree with it, but I don't
agree with normative enforcement in the data format. I will do
whatever I possibly can to make sure the Guide gets the attention it
deserves. I will write drafts of the section in question, if that's
what it takes. Do you want it to receive the most prominent placement
on atomenabled.org and atompub.org? I'm sure that could be arranged.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Thu, 12 May 2005 01:31:57 +0100

Robert,

I'm trying to include you in this discussion and you're not  
cooperating. You are the only person in the WG who has said there  
shouldn't be any recommendation in the specification. You are vastly  
outnumbered by people who've stated they'd be OK with it. The only  
question now is the wording.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Wed, 11 May 2005 20:52:55 -0400

> question now is the wording.

Is that right? I don't think it is. If you think I've stated something
incorrectly, make your opinion known to the IESG.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 12 May 2005 01:51:53 +0100

Graham wrote:

> The "Implementor's Guide" may or may not ever exist and may or may  not 
> be read by anyone, so that isn't an option. 

The WG has tended to punt assuming on a Fabled Implementors Guide. Why 
is that punt not acceptable now?

> Myself and Sam, and  (I 
> think) Tim and Antone, would all like the actual spec to make an  actual 
> recommendation that entries without enclosed content include a  textual 
> summary, if at all possible. 

Bray voiced concerns about SHOULD; I suggested MAY. No further
discussion occurred. What might be wrong with a MAY requirement in this
case?

> Note no one wants to ban title- only feeds 
> if they come from title-only resources. 

I've claimed here before that kind of reasoning is the same kind of
reasoning that lead us to reject 3 dates. It's not something we can
manage. What is different here?

[Also, the nature of resources ensures this is outside our scope; unless 
  we're breaking with web arch, we deal squarely with representations; 
granted I may be reading too much into what you mean by resource, but 
I'm assuming its usage is technical until told otherwise.]

> What language  would you find 
> acceptable that covers these bases?

Language that doesn't result in confusion. Sam's text pace makes 
title-only feeds bad practice. I'm not satisfied the text pace has 
adequate language - the rationale presented is weak, the SHOULD 
requirement level isn't entirely appropriate, the idea of deliberately 
issuing mixed messages from the spec is unsatisfactory. I've pushed back 
on this pace a few times now and haven't seen any good answers as a 
result of that. At some point someone really ought to provide a clear 
explanation of its value. What have I already said that you think is 
wrong so that I should change my position?

cheers
Bill

---

From: Graham <[email-masked]>
Date: Thu, 12 May 2005 02:22:08 +0100

On 12 May 2005, at 1:51 am, Bill de hÓra wrote:

> The WG has tended to punt assuming on a Fabled Implementors Guide.  
> Why is that punt not acceptable now?

I know putting things in the IG has been mentioned before, but I  
can't think of any actual cases where that was the outcome of the  
debate - things have either been put in the spec, or rejected  
outright. This needs to go in the spec. It's just as much of an  
techical/interop issue as "Logos must have a 2:1 aspect ratio".

> discussion occurred. What might be wrong with a MAY requirement in  

MAY is fine as the actual RFC term, but needs to be embellished, eg:

"atom:summary MAY be included, but software is encouraged to do so  
when atom:content is not present"

As I've said before, I don't know what the exact wording needs to be.  
Is there an RFC-compatible way to get the intention of this sentence  
across? This question is put mainly to the chairs and the AD, btw.

Graham

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 May 2005 19:42:08 -0700

At 2:22 AM +0100 5/12/05, Graham wrote:
>As I've said before, I don't know what the exact wording needs to 
>be. Is there an RFC-compatible way to get the intention of this 
>sentence across? This question is put mainly to the chairs and the 
>AD, btw.

The quoted sentence would be fine in an RFC. It gives a clear 
compliance level (MAY), it gives advice about why one would want to 
or not want to use it. A slight quibble: I would change "but" to 
"and". But it world work fine as stated.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Antone Roundy <[email-masked]>
Date: Wed, 11 May 2005 21:12:30 -0600

On Wednesday, May 11, 2005, at 06:09  PM, Robert Sayre wrote:
> available from a blog or news site

This is an excellent way to state a large portion of my opinion on this 
subject.  Let me see if I can state it completely and concisely:

1) I'd like to encourage people to publish useful feeds, and give them 
guidance about how to do so
2) I'd like to strongly encourage people to publish accessible feeds

The rest is details:

* What makes a feed useful?
-- In most cases, having enough content for it to be a reliable tool 
for deciding whether to follow a link to more content.
-- In some cases, having a nothing more than the consuming application 
is going to use--for example, a news headline ticker basically needs a 
headline, a link, and timestamp and an ID.

* How does one achieve the goal of publishing a useful feed?
-- For the most common case, include atom:summary or atom:content.
-- For the less common case, include neither atom:summary nor 
atom:content.
The two conflict with each other.  Thus, I'd like to encourage people 
to at least publish a feed to cover the first case, but in no way 
prevent them from also publishing a stripped down version for the 
second case.  If they really want to or only can, they should be 
allowed to only cover the second case.

* What makes a feed accessible?
-- If the feed has "content", including a textual version or summary of 
it in one of Atom's special formats ("text", "html" and "xhtml").

I think that captures what I would hope we can find language to 
achieve.  I don't think we're going to achieve that by simply deciding 
between SHOULD and MAY.

> when atom:content is not present"

How about something along the lines of:

"atom:summary is OPTIONAL, but when atom:content is either not present, 
or when the value of its type attribute is anything other than "text", 
"html" or "xhtml", publishers are strongly encouraged to either include 
atom:summary, or publish another version of the feed which includes 
atom:summary or atom:content with one of the type attribute values 
listed above."

In the above, 'anything other than "text", "html" or "xhtml"' could be 
replaced by 'a MIME media type', and correspondingly "one of the type 
attribute values listed above" with something like 'a type attribute 
value of "text", "html" or "xhtml"'.

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Thu, 12 May 2005 07:56:28 -0400

Paul, Tim:

It would be helpful if you could address the "The current draft fails to
satisfy the second bullet point" allegation.

-Scott-

> -----Original Message-----
> From: Robert Sayre [mailto:[email-masked]] 
> Sent: Wednesday, May 11, 2005 2:00 PM
> To: [email-masked]
> Cc: Robert Sayre; Sam Hartman; Atom-Syntax
> Subject: Re: Last Call: required summary or content?
> 
> 
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 May 2005 08:19:40 -0700

>>  The current draft fails to satisfy the second bullet point.

I don't see how. The current document certainly shows how to create 
entries with enclosed content (the entry can contain an atom:content 
element), and it certainly shows how to create entries with no 
enclosed content (the entry can contain no atom:content elements).

>  > Sam Ruby: http://www.imc.org/atom-syntax/mail-archive/msg14057.html

Those two personal opinions, neither of which appears in the current 
draft, do not relate to the charter-level description of "enclosed 
content". In the case of the charter, "enclosed content" means an 
atom:content element, no other parts of the entry. If we took this 
too the extreme Rob wants, we would have to allow completely null 
entries because titles, dates, and even IDs could be considered 
content.

--Paul Hoffman, Director