On Monday, May 9, 2005, at 02:43 PM, Robert Sayre wrote:
Did you see this email? Did you notice all the questions about the technical basis of your position? Maybe you should answer them.
Also, I'm having trouble reconciling your road lying with the assertion that the two proposals are compatible. How can they be if their outcomes are so different?
The change to the spec text proposed by PaceOptionalSummary would also be made by PaceTextShouldBeProvided. In that way, they are compatible. The intents of the authors in writing them was different. In that way, they are incompatible.
The intents of people who gave them +1 are not 100% clear. My interpretation is that if someone gave PaceOptionalSummary a +1, but not PaceTextShouldBeProvided, then their intent is close to the author of PaceOptionalSummary. If they gave both a +1, then either they could live with either MAY or SHOULD in the proposed change to section 4.1.2, or their intent is close to the author of PaceTextShouldBeProvided (and they consider the two basically compatible for the reason noted above--ie. looking at the proposed changes to the spec, and not worrying about the authors' intents). I'm in the former group--okay with either MAY or SHOULD. I'd lean more toward SHOULD if we were to come up with a good way to say "if there's content, but it's not in atom:content in one of our three special formats, then there SHOULD be a summary"--in other words, if one of the following applies:
* atom:content/@type is a MIME type rather than "text", "html" or "xhtml"
* there is no atom:content, and some extension element holds the core content of the entry
Note that I don't list "no atom:content and no extension element holding the content"...that's where I lean towards MAY, because to me, the biggest reason for strongly encouraging the use of atom:summary is accessibility. If there's no atom:content or substitute element, then nobody is less able to access the content of the entry than anyone else, because there is no "content" outside of the metadata elements.
The problem with the above is that bullet point #2 isn't checkable without agreement on what constitutes a core-content-holding-extension-element. I don't even want to try to come up with language to describe that--I've participated in this group too long to be that foolish.
On 5/9/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:I think, more or less, that PaceTextShouldBeProvided only exists because
PaceOptionalSummary has not been successfully dismissed. I have no idea
why title-only feeds are unfortunate, are an interoperability problem,
or an accessibility problem. In fact I felt we had put the accessibility
issue to bed weeks ago, but it popped up again in the
PaceTextShouldBeProvided's rationale.
I have no problem with title only feeds. I myself would be far less likely to subscribe to them--or at least they'd have to have extraordinarily well-written, informative titles for me to subscribe to them in just about all cases--but there are certainly valid uses for them.
