Re: PaceTextShouldBeProvided vs PaceOptionalSummary

2005-05-07 Thread Roger B.

 Yes. If that SHOULD goes through, it becomes OK to write an Atom
 Processor that catches fire when summary and content are both absent.

Robert: Nothing about either pace will make it not OK to drop
content- and summary-free entries on the floor, or come to a full stop
when they're encountered. Such feeds would be completely useless in
some apps, and therefore deserve to be tossed.

PaceOptionalSummary simply enables an infinite loop of talk to the
other guy about that responses to user questions, while
PaceTextShouldBeProvided says that the tie goes to the aggregator.

Kinda funny when you look at it that way, given the heated discussion
on the subject. They could both be rolled into a single
PaceWhoYouGonnaBlame and save everyone unnecessary reading.

--
Roger Benningfield



Re: PaceTextShouldBeProvided vs PaceOptionalSummary

2005-05-06 Thread Bill de hÓra
Tim Bray wrote:
Speaking not as the chair but as an interested WG member,  I read them 
about eight times and I do not understand why they are in conflict.  
Someone please explain, as simply as possible, what the problem is, 
because I just don't get it.  On the face of it, I am inclined to be +1 
to both PaceOptionalSummary and PaceTextShouldBeProvided.

1. The pace's rationale has claims which have already been refuted by 
Robert and others in the discussion on optional summaries:

 Encourage interoperability and accessibility
this rationale has no merit, imo.
2. It has a bias that is squarely aimed at title only feeds, which is 
the outcome of PaceOptionalSummary

 Unfortunately, there are also existence proofs of title-only feeds
it clearly takes a shot across the bows of PaceOptionalSummary.
3. It's the kind of spec text we have rejected in the past as 
impletation specific and/or best current practice guidance:

 those that follow these suggestions will find that their feeds are 
useful to a wider audience than they would be otherwise.

we have a decision making legacy that speaks for itself, this is not 
demstrated to be a special case we ought to cater for.

4. It would appear to contradict PaceOptionalSummary by highlighted that 
 legal usage as bad practice. That's contradictory in spirit, and 
personally speaking it's the kind of wording and deliberate vagueness 
that infuriates me about software specs. fFutzing about like this is 
showing poor form to the users of the spec

2 alone should be enough for you. Technically these things are not in 
contradiction, in sprit they are.

I'm on the record already here:
http://www.imc.org/atom-syntax/mail-archive/msg14535.html
cheers
Bill


Re: PaceTextShouldBeProvided vs PaceOptionalSummary

2005-05-06 Thread Sam Ruby
Bill de hÓra wrote:
3. It's the kind of spec text we have rejected in the past as 
impletation specific and/or best current practice guidance:

 those that follow these suggestions will find that their feeds are 
useful to a wider audience than they would be otherwise.
Um, that text is not part of the proposal.  It is part of the rationale.
- Sam Ruby


Re: PaceTextShouldBeProvided vs PaceOptionalSummary

2005-05-05 Thread Tim Bray
On May 5, 2005, at 11:02 AM, Robert Sayre wrote:
I don't see a conflict there. What's wrong with accepting two similar
paces because one corrects the flaws in the other?
Graham, that's just not true. It wasn't called
PaceSummariesAreNotRequired, was it? It materially changes the only
action PaceOptionalSummary takes. They are not compatible.
In fact, let's get the chairs to clarify this.
Speaking not as the chair but as an interested WG member,  I read them 
about eight times and I do not understand why they are in conflict.  
Someone please explain, as simply as possible, what the problem is, 
because I just don't get it.  On the face of it, I am inclined to be +1 
to both PaceOptionalSummary and PaceTextShouldBeProvided.

Note: I totally fail to understand the Notes bit at the end of 
PaceTextShouldBeProvided.  It is underspecified to the extent that I 
can't figure out what language change it is actually saying is 
necessary.

Basically, allowing title-only feeds seems OK to me, and encouraging 
people to provide text also seems OK to me, so what's the problem?  In 
fact, these seem pretty orthogonal; it seems quite plausible that one 
could like either of these without liking both.  -Tim



Re: PaceTextShouldBeProvided vs PaceOptionalSummary

2005-05-05 Thread Tim Bray
On May 5, 2005, at 3:52 PM, Robert Sayre wrote:
Everything in the proposal section is fine with me, as well. It's that
Notes section that's the problem.
Note: I totally fail to understand the Notes bit at the end of
PaceTextShouldBeProvided.  It is underspecified to the extent that I
can't figure out what language change it is actually saying is
necessary.
That section says is If PaceOptionalSummary is 'accepted', this Pace
changes summary to SHOULD. That's OK to propose, but you can't accept
both of them. They conflict.
No it doesn't, it says something about inserting the phrase ...is 
either not present or... which, by the way, I don't understand.  Are 
we looking at the same document?

Basically, allowing title-only feeds seems OK to me, and encouraging
people to provide text also seems OK to me, so what's the problem?
Current spec: MUST contain a summary
after PaceOptionalSummary: MAY contain a summary
after PaceTextShouldBeProvided: SHOULD contain a summary
So what you're actually objecting to is the last part of the Pace 
before the Impacts section, that wants 4.1.2 to say that summary 
SHOULD be there if Content is absent.  Or am I missing something? -Tim



Re: PaceTextShouldBeProvided vs PaceOptionalSummary

2005-05-05 Thread Robert Sayre

On 5/5/05, Tim Bray [EMAIL PROTECTED] wrote:

 
 No it doesn't, it says something about inserting the phrase ...is
 either not present or... which, by the way, I don't understand.  Are
 we looking at the same document?

Ah, it's been updated since I last looked. The proposed text for 4.1.2
didn't used to account for an absent content element.
 
  Basically, allowing title-only feeds seems OK to me, and encouraging
  people to provide text also seems OK to me, so what's the problem?
 
  Current spec: MUST contain a summary
  after PaceOptionalSummary: MAY contain a summary
  after PaceTextShouldBeProvided: SHOULD contain a summary
 
 So what you're actually objecting to is the last part of the Pace
 before the Impacts section, that wants 4.1.2 to say that summary
 SHOULD be there if Content is absent. 

Yes. If that SHOULD goes through, it becomes OK to write an Atom
Processor that catches fire when summary and content are both absent.
That is not what the folks who supported PaceOptionalSummary were
advocating. They conflict.

Robert Sayre



Re: PaceTextShouldBeProvided vs PaceOptionalSummary

2005-05-05 Thread Robert Sayre

On 5/5/05, Tim Bray [EMAIL PROTECTED] wrote:
 
 Speaking not as the chair but as an interested WG member,  I read them
 about eight times and I do not understand why they are in conflict.
 Someone please explain, as simply as possible, what the problem is,
 because I just don't get it.  On the face of it, I am inclined to be +1
 to both PaceOptionalSummary and PaceTextShouldBeProvided. 

Everything in the proposal section is fine with me, as well. It's that
Notes section that's the problem.

 Note: I totally fail to understand the Notes bit at the end of
 PaceTextShouldBeProvided.  It is underspecified to the extent that I
 can't figure out what language change it is actually saying is
 necessary.

That section says is If PaceOptionalSummary is 'accepted', this Pace
changes summary to SHOULD. That's OK to propose, but you can't accept
both of them. They conflict.

 
 Basically, allowing title-only feeds seems OK to me, and encouraging
 people to provide text also seems OK to me, so what's the problem? 

Current spec: MUST contain a summary
after PaceOptionalSummary: MAY contain a summary
after PaceTextShouldBeProvided: SHOULD contain a summary

Robert Sayre



Re: PaceTextShouldBeProvided vs PaceOptionalSummary

2005-05-05 Thread Graham
On 6 May 2005, at 4:26 am, Robert Sayre wrote:
PaceTextShouldBeProvided: SHOULD have a summary
PaceOptionalSummary: MAY have a summary
No, Robert:
Current situation: MUST have a summary
PaceOptionalSummary: No explicit opinion
PaceTextShouldBeProvided: SHOULD have a summary
PaceOptionalSummary simply says remove the MUST, it doesn't say  
what it should be replaced with.

Graham


Re: PaceTextShouldBeProvided vs PaceOptionalSummary

2005-05-05 Thread Robert Sayre

On 5/5/05, Graham [EMAIL PROTECTED] wrote:

 
 PaceOptionalSummary simply says remove the MUST, it doesn't say
 what it should be replaced with.

What part of OPTIONAL don't you understand? 

Robert Sayre