On 4/27/05, Sam Ruby <[EMAIL PROTECTED]> wrote: > Robert Sayre wrote: > > On 4/27/05, Sam Ruby <[EMAIL PROTECTED]> wrote: > > > >>Actually, that's one of the key reasons why I like the MUST for summary. > >> If somebody invents a popular hoffman:content-plus-plus, then feeds > >>that include it lieu of atom:content will need to include a human > >>readable summary that can be used by existing clients. > > > > If they nest a content-plus-plus inside atom:content, they wouldn't > > have to include that summary, right? > Simply put: my recollection was that we were successful in killing > PaceNukeMultipart with the argument that every entry would have some > displayable text (either plain, html, or xhtml).
My recollection is that we were successful in removing multipart content because references to linked alternates would have sufficient granularity to provide accessible alternatives. If there were multiple content elements, an entry would need to provide references for each of those elements, and start to look like a feed itself. I don't lend much weight to either of our recollections, though. Those discussions were disorganized, rude, and full of intimidation. > That's pretty much orthogonal to the discussion we are having here > (i.e., if an entry does not have any summary or content, then it doesn't > discriminate - it is equally as inaccessible to everybody); My opinion is that ~10 WG members are currently clearly stating their belief that summary/content are optional. > but if that > was the actual intent of the consensus, then the document should be > updated to reflect that. If you are suggesting that the format should require a summary for more non-empty types of content than it currently does, I don't have an objection to that, but we'll have to see a Pace. > Furthermore, it would rule out the tunneling > of hoffman:content-plus-plus as a dodge to avoid providing a summary > that could be understood by existing clients. I don't think we can defend ourselves from bad-faith publishers. Robert Sayre
