Bill:
That last objection in parens sounds like some of the positions held around dates - that providers ought to do the right thing for some definition of the right thing. Given that legacy, I'll claim it's clear we're not here to police what people ought do with feeds that could have a summary.
Graham:
Then what are we here to do? Would you support removing all of the other requirements from the spec?
> Sam: > First, note that this is misstating Graham's position. > He is not arguing that summaries be made non-optional.
I support discussing requirements that can be framed operationally and which induce a benefit. This is why I keep coming back to title-only feeds rather than concerning myself with enforcing some sort of policy on what people think other people ought to do with summaries. Rationales along the lines of "we object to feeds that could have a summary included but don't", don't work for me, and I'll try to explain why here. I also (and this is possibly unfair to Graham) think that when counter-factual arguments are being presented against, then the argument against the pace are running out of steam.
And if Robert's assertion elsewhere ("Every bit of syndication code written since my.netscape.com in 1999 can deal with title-only feed") is remotely true , ie there's not large number of codebases that will break, then you can add innovation through standards to my list of objections to any position that makes summaries non-optional.
Every code base can also cope without dates or ids. We still require them.
Yes, and there we agreed not to require enforcing publishers to update on every change and have 3 date items to support that policy. Largely because it can't be enforced and downstream clients will end up baking bad assumptions into their tools.
My point here is probably worth elaborating on. I feel the same way about the must-be including summaries because you should be including summaries position, as I did about the must be updating dates because you should be updating dates position, that they are usefully enforceable. I also feel the same way about insisting on empty summary elements if that is used to obtain a compromise. I'm well aware of SHOULDs and optionals causing interop issues, however this must have summary approach, like must update timestamps, is not the kind of constraint that induces useful behaviour.
I've read and re-read the -1 positions to PaceOptionalSummary and I can neither see the harm in optional summaries nor the benefit in always having a summary. That is, operationally, I can't see what harm is caused by allowing title-only feeds or what the benefit of disallowing them is. But I can see the pointlessness, if not quite harm, of making people populate a field they either don't need or don't want to populate. I suspect that might induce junk data unneccesarily.
I believe I understand the -1 position, but I just haven't be swayed by the arguments for it; that leaves me at +1.
cheers Bill
