Tim Bray wrote:
http://www.intertwingly.net/wiki/pie/PaceOptionalSummary
0
As editor of the one the protocols cited in favour (HTTPLR) I'd like to
clarify this position, especially as the debate around this issue has
imo been emotionally charged; most recently there's been talk of
Tim Bray wrote:
I was driving to the airport with Lauren, whom some of you will know,
she's technical but hasn't been following Atom. I explained the debate
we are having over the required-ness of atom:summary, and she said
Don't you have anything better to talk about? I suspect she has a
The feedvalidator catches silly, boring corner-cases every day.
I hesitate to bring it up again as it has proven to incite adhominen
attacks from within this workgroup, but we have an example of a
respected journalist who has published a book in which he specifically
called out this.
So?
Does much of this debate come down simply to whether there is a
distinction between an empty summary and an absence of a summary?
I am in favour of an optional summary because if there is no summary, I
would rather not see summary/
I can understand that people that don't have a problem with
I'd be willing give a +1 to SHOULD language regarding summary/content.
I'd prefer one or the other be required for a weblog-centric format
like Atom, but I'll just do what I already do with title-only RSS
feeds... have my code reject them as inadequate.
--
Roger Benningfield
Do the following messages mean the same thing?
Robert: In my app? Yep, exactly the same.
--
Roger Benningfield
On 4/26/05, Roger B. [EMAIL PROTECTED] wrote:
I'd be willing give a +1 to SHOULD language regarding summary/content.
That's not good enough. You have to demonstrate an interop problem to
say SHOULD or MUST.
I'd prefer one or the other be required for a weblog-centric format
like Atom, but
On 26 Apr 2005, at 8:54 pm, Robert Sayre wrote:
On 4/26/05, Roger B. [EMAIL PROTECTED] wrote:
I'd be willing give a +1 to SHOULD language regarding summary/content.
That's not good enough. You have to demonstrate an interop problem to
say SHOULD or MUST.
So your app sends me an Atom document that
On Tuesday, April 26, 2005, at 02:49 PM, Graham wrote:
So your app sends me an Atom document that looks like this:
entry
idwhetever/id
titleSo Caleb is Lindsey's father/title
/entry
What does this mean?
a) A title only feed
b) A full entry with the summary missing.
Without knowing this (which it
On 26 Apr 2005, at 9:53 pm, Robert Sayre wrote:
On 4/26/05, Graham [EMAIL PROTECTED] wrote:
Without knowing this (which it wouldn't under Tim's proposal), my app
can't reliably interoperate with yours.
I have no idea what you're talking about. Do the feeds on
craigslist.org interoperate? Yes or
On 4/26/05, Graham [EMAIL PROTECTED] wrote:
If I write an app that needs to know whether an entry had a body that
was removed or is a title-only feed,
uh, what's the difference.
it cannot interoperate with Atom
feeds under Tim's proposal because there is no difference between them.
This
Graham wrote:
On 26 Apr 2005, at 9:53 pm, Robert Sayre wrote:
On 4/26/05, Graham [EMAIL PROTECTED] wrote:
Without knowing this (which it wouldn't under Tim's proposal), my app
can't reliably interoperate with yours.
I have no idea what you're talking about. Do the feeds on
craigslist.org
That's not good enough. You have to demonstrate an interop problem to
say SHOULD or MUST.
Interop with *what*, Robert? What's the baseline?
No aggregator *requires* a title... one can be synthesized.
No aggregator *requires* an id... links, hashes, and so on do the job
sufficiently for most
* Tim Bray [EMAIL PROTECTED] [2005-04-25 20:35]:
I decided it would help if there was an actual Pace:
http://www.intertwingly.net/wiki/pie/PaceOptionalSummary
So far I havent seen a cogent explanation of the significant
semantics offered by an empty atom:summary inside an otherwise
valid
On 4/26/05, Roger B. [EMAIL PROTECTED] wrote:
And so on... I honestly can't think of a single child of atom:entry
that is required for interop.
Yeah, I agree. The WG does not, however. They do happen to agree with
me on this issue.
No one needs Atom for producing a title-and-link feed.
This argument has a got a bit sidetracked. My position is:
a) I think title-only feeds should be allowed where there's nothing
sensible to put in the summary or content elements.
b) Under all other circumstances, a summary of some kind should be
required when atom-based textual content is
Graham wrote:
This argument has a got a bit sidetracked. My position is:
a) I think title-only feeds should be allowed where there's nothing
sensible to put in the summary or content elements.
b) Under all other circumstances, a summary of some kind should be
required when atom-based textual
On 4/26/05, Sam Ruby [EMAIL PROTECTED] wrote:
Graham wrote:
The pace as written newly allows the omission of a summary and content
on the whim of the publisher.
That's right.
I'm within my rights as a
consumer to reject title-only feeds as not worth bothering with (before
you
At 10:02 PM -0400 4/26/05, Bob Wyman wrote:
Paul Hoffman wrote:
The intermediary can, however, add a signed extension that
says this message was earlier signed by Xyzzy, and we verified that
signature before we changed things.
Forgive me if I'm missing something obvious... While I
On 4/26/05, Tim Bray [EMAIL PROTECTED] wrote:
Paul I are gonna watch a little more debate and then
we'll call rough consensus one way or the other, at which point I at
least will become crushingly rude to anyone who wants to invest more
time in this.
Yeah, so now Sam and Graham are off
Robert Sayre wrote:
On 4/26/05, Sam Ruby [EMAIL PROTECTED] wrote:
Graham wrote:
The pace as written newly allows the omission of a summary and content
on the whim of the publisher.
That's right.
I'm within my rights as a
consumer to reject title-only feeds as not worth bothering with (before
+1
On Apr 25, 2005, at 5:10 PM, Tim Bray wrote:
On Apr 25, 2005, at 3:49 PM, Mark Nottingham wrote:
Comments on the media type template.
He's got a point on the namespace being mentioned, which creates some
semi-circular dependencies, sigh. As to whether it's currently in
use, largely due to
22 matches
Mail list logo
