Re: PaceOptionalSummary
Let's forget about Paces for a minute. Does anyone disagree with the principal of recommending publishers include summaries if they have them available, and aren't supplying atom:content? Don't worry about how it might be worded for now, just the principal. Graham
Re: PaceOptionalSummary
Robert Sayre wrote: On 5/9/05, Sam Ruby [EMAIL PROTECTED] wrote: I also feel the need to express deep dismay at the way that author of PaceOptionalSummary has been pursuing a scorched earth approach whereby everybody who expresses an opinion to the contrary is viciously attacked for doing so. I believe that this has significantly hampered the ability of the work group to hold a reasonable discourse on the subject. I believe the secretary significantly hampered discourse on this subject for *months*, by claiming the issue had consensus and was closed. It appears that the scorched earth campaign is destined to continue unabated. It is an interesting theory, now lets explore the facts. The secretary's job is to schedule the discussion of Paces. PaceOptionalSummary was authored on 2005/04/30, and scheduled on 2005/05/05. PaceOptionalSummary was preceded by PaceCoConstraintsAreBad, which was authored on 2005/04/06. It, too, was scheduled in the very next round of paces. I agree with Robert; it conflicts with PaceOptionalSummary and I doubt it would exist if PaceOptionalSummary had not make the cut. -1 as well. Doesn't solve a technical problem. It's just gamesmanship. Alternate theory. After months of foreshadowing, PaceOptionalSummary was exquisitely timed to coincide with last call. Along with a diversionary burst of fire concerning alleged process issues. Here's where SHOULD comes in. We're lucky that we have an example of what happens when a SHOULD is violated. I'm sure most of you saw the nasty arguments, accusations, and all-around busted software that happen this week with Google Web Accelerator and Ruby On Rails.[0] Ugly, right? This WG should be proud that we've kept the SHOULDs to a minimum. Interesting analogy, let's see how it pans out. The W3C could have made idempotency a MUST, which effectively would have prevented useful things like hit counters. Or they could have made idempotency a MAY, slamming the door shut not only things like Google's WebAccelerator, but also on all web crawlers. Instead, they decided to make idempotency a SHOULD, opening the door for web crawlers by putting servers on notice that in the event of a conflict, the onus is on them. - - - Back to Atom. If a entry in a feed does not include a title, and Firefox's Live Bookmark support choses not to display it, who is the onus on? If an entry in a feed contains neither a textual content nor a summary, and Walter's search engine choses not to index it, who is the onus on? Simply put, PaceOptionalSummary is incomplete. 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? In my note yesterday morning, I made it abundantly clear what I objected to. It wasn't the text between the ==Proposal== and ==Impacts== markers. - - - The W3C got it right. And so should we. Answer the two questions above. Without hysterics like burst into fire. What we actually are talking about here is aggregators that drop information on the floor. Should we warn producers about this? - Sam Ruby
Re: PaceOptionalSummary
Sam Ruby wrote: ... The W3C could have made idempotency a MUST, which effectively would have prevented useful things like hit counters. ... Not true. Quoting RFC2616: In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered safe. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. ... Best regards, Julian
Re: PaceOptionalSummary
On 5/10/05, Sam Ruby [EMAIL PROTECTED] wrote: Back to Atom. If a entry in a feed does not include a title, and Firefox's Live Bookmark support choses not to display it, who is the onus on? No one. The spec doesn't say anything about what must be displayed. If an entry in a feed contains neither a textual content nor a summary, and Walter's search engine choses not to index it, who is the onus on? No one. The spec doesn't say anything about what must be persisted. Should we warn producers about this? No. These are application-specific issues. Every application is different. Robert Sayre
Re: PaceOptionalSummary
On Tuesday, May 10, 2005, at 05:37 AM, Graham wrote: Let's forget about Paces for a minute. Does anyone disagree with the principal of recommending publishers include summaries if they have them available, and aren't supplying atom:content? Yes. Note that I also recognize the legitimacy of publishing a feed without the summary, even if available, in some circumstances--hopefully in an alternative version of the feed (ie., hopefully there's a version of the feed with summaries or content, and a special-purpose one without). That'd lead to a SHOULD, right?
Re: PaceOptionalSummary
On May 10, 2005, at 4:37 AM, Graham wrote: Let's forget about Paces for a minute. Does anyone disagree with the principal of recommending publishers include summaries if they have them available, and aren't supplying atom:content? Yes, but I'd go further; I'd like to encourage, in general, producers to put more than less stuff in feeds, and provide a summary whenever they possibly can. My only angst at this moment is whether the canonical SHOULD is the right tool to do that. -Tim
Re: PaceOptionalSummary
Tim Bray wrote: On May 10, 2005, at 4:37 AM, Graham wrote: Let's forget about Paces for a minute. Does anyone disagree with the principal of recommending publishers include summaries if they have them available, and aren't supplying atom:content? Yes, but I'd go further; I'd like to encourage, in general, producers to put more than less stuff in feeds, and provide a summary whenever they possibly can. My only angst at this moment is whether the canonical SHOULD is the right tool to do that. -Tim MAY is the requirement level I would choose for something like a summary, which isn't a control code or interoperability hotspot. My sense of things, based on the paces and discussion I've seen, is that MAY won't accord sufficient moral obligation to gain consensus here. Perhaps that can be offset by producing text that urges the publisher to consider emitting summaries. cheers Bill
Re: PaceOptionalSummary
* Bill de hra [EMAIL PROTECTED] [2005-05-10 17:00]: Perhaps that can be offset by producing text that urges the publisher to consider emitting summaries. Maybe its something for the implemetors guide as opposed to the spec, then? Regards, -- Aristotle
Re: PaceOptionalSummary
On 5/10/05, Bill de hÓra [EMAIL PROTECTED] wrote: MAY won't accord sufficient moral obligation to gain consensus here. Perhaps that can be offset by producing text that urges the publisher to consider emitting summaries. Or, we could figure out a way to let the client ask for the amount of information it desires, rather than legislate morality. http://www.franklinmint.fm/blog/archives/000381.html After all, we're not having discussions on how many entries there should be in a feed. The amount of work on content negotiation/instance manipulation of feed resources should indicate there is no right answer to these questions. Robert Sayre
Re: PaceOptionalSummary
A. Pagaltzis wrote: * Bill de hra [EMAIL PROTECTED] [2005-05-10 17:00]: Perhaps that can be offset by producing text that urges the publisher to consider emitting summaries. Maybe its something for the implemetors guide as opposed to the spec, then? I raised that question already: http://www.mail-archive.com/atom-syntax@mail.imc.org/msg02809.html the WG didn't discuss it in follow-up (I think). cheers Bill
Re: PaceOptionalSummary
On 5/10/05, A. Pagaltzis [EMAIL PROTECTED] wrote: * Bill de hÓra [EMAIL PROTECTED] [2005-05-10 17:00]: Perhaps that can be offset by producing text that urges the publisher to consider emitting summaries. Maybe it's something for the implemetor's guide as opposed to the spec, then? That's one option. If the implementor's guide were a BCP RFC, it would be easy to flag in a feed validator. The validator at feedvalidator.org spits out a pretty scary warning when it decides to warn (example: javascript in html content). Many people mistake the warnings for an error, because the little 'valid' badge is buried under the warning message and source code. A BCP RFC could be used as fodder for a less-scary looking warning. Something like This feed may not follow established best practices. Another option would be to give title-only entries an intimidating name in the spec. Something like Entries that lack both an atom:summary and an atom:content are termed 'Content-Free'. Or we could do both. Robert Sayre
Re: PaceOptionalSummary
Antone Roundy wrote: +1. ...oh, and the wording I just suggested for part of PaceTextShouldBeProvided would depend on this also being accepted. With deep regret, I'm going to express my -1 on PaceOptionalSummary. Not because I object to the text expressed in the proposal section. In fact, I clearly do not as I lifted large sections of it to be placed into PaceTextShouldBeProvided. No, it is because the author of PaceOptionalSummary has made it clear that he interprets the two paces to be incompatible, so each and every +1 for PaceOptionalSummary is a vote against PaceTextShouldNotBeProvided. Despite wording that accompanied several of these +1's, like the wording describe above. I also feel the need to express deep dismay at the way that author of PaceOptionalSummary has been pursuing a scorched earth approach whereby everybody who expresses an opinion to the contrary is viciously attacked for doing so. I believe that this has significantly hampered the ability of the work group to hold a reasonable discourse on the subject. Despite this, I have attempted to see if there was some common ground to be found. I drafted up a Pace, and offered a few suggestions. It has since become clear to me that PaceOptionalSummary is being pursued in a winner take all manner. As such, I see no other path than to offer my -1 on the Pace. Face down, arms and legs outstretched, in the middle of the road. One thing I would like those who advocate PaceOptionalSummary to the exclusion of all other Paces on the subject to consider... what happens if the chairs determine that consensus can't be found on either of these paces? Look at the current wording of draft-08. Is that what you really want? We can do better. - Sam Ruby
Re: PaceOptionalSummary
On 9 May 2005, at 1:19 pm, Sam Ruby wrote: I also feel the need to express deep dismay at the way that author of PaceOptionalSummary has been pursuing a scorched earth approach whereby everybody who expresses an opinion to the contrary is viciously attacked for doing so. I believe that this has significantly hampered the ability of the work group to hold a reasonable discourse on the subject. Plus fucking one. As such, I see no other path than to offer my -1 on the Pace. Face down, arms and legs outstretched, in the middle of the road. -1 also. Graham
Re: PaceOptionalSummary
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.
Re: PaceOptionalSummary
I have no problem with title only feeds. I'm -1 on POS, although I wouldn't describe myself as being positioned in the path of oncoming traffic. Title-only feeds have valid uses, but they're really out of scope for a feed format that only exists because it provides a clearer, cleaner way to deliver content. -- Roger Benningfield
Re: PaceOptionalSummary
On 5/9/05, Antone Roundy [EMAIL PROTECTED] wrote: 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. Do you expect a conformant Atom Processor, such as Jakarta FeedParser, to successfully process title-only feeds? Robert Sayre
Re: PaceOptionalSummary
On 5/9/05, Roger B. [EMAIL PROTECTED] wrote: I have no problem with title only feeds. I'm -1 on POS, although I wouldn't describe myself as being positioned in the path of oncoming traffic. Title-only feeds have valid uses, but they're really out of scope for a feed format that only exists because it provides a clearer, cleaner way to deliver content. Roger, please don't see this as an attack. Here's our charter: -- The format must be able to represent: ... * a feed or channel of entries, with or without enclosed content ... -- I don't think there's a scope argument here. Robert Sayre
Re: PaceOptionalSummary
Robert Sayre wrote: On 4/28/05, Roger B. [EMAIL PROTECTED] wrote: Do you have an example? Robert: I'm an example. I also drop title-free feeds (see Scripting News)... given the nature of the app, a feed without titles or content is just worthless. That's fine, but we're not here to tailor the format to your app. Robert: why did you ask for an example? - Sam Ruby
Re: PaceOptionalSummary
On 4/28/05, Sam Ruby [EMAIL PROTECTED] wrote: Robert: why did you ask for an example? To find out about any technical issues, not to hear Roger repeat himself. Robert Sayre
Re: PaceOptionalSummary
Sorry, what was your point again? Eric: The point was that the *application* drops title- or content-free entries. It never inserts them into the database. They go poof. -- Roger Benningfield
Re: PaceOptionalSummary
On 4/28/05, Roger B. [EMAIL PROTECTED] wrote: That's fine, but we're not here to tailor the format to your app. Robert: Seriously, dude. C'mon. You're right, that was too snippy. But you asked a question, and I answered it. Honestly, straightforwardly, and without an weasel-words. I did not ask anyone to tailor anything to anything. Try that silly crap with others if you must, but spare me. Again, I support a SHOULD on summary. Not just adding an empty element... allowing publishers to drop it entirely, as long as they're aware they're doing something that will have an impact on the primary functionality of feed-consuming applications. Your argument is mostly consistent. I'll try to explain why SHOULD will create problems that don't exist today. Let's take del.icio.us. Sometimes, their entries have descriptions. Sometimes, they don't. Your SHOULD allows competitors to turn off their feeds at any time, and point to the spec as justification. Even worse, it could be oh, some of their entries are buggy, so we drop those. I doubt your intent is anything nearly that malicious, and you might be right that the feeds in question suck, but using a SHOULD to back up that action is exactly what we want to avoid. It might even be possible to write a naive parser that actually malfunctioned on such feeds. Basically, if what you say is true, we don't need to enforce a summary at all. It'll take care of itself, like email and even HTML eventually did (it's possible to create an entire page in Flash, but not particularly effective in the market). If these sorts of feeds are legitimate for a certain style of application, a SHOULD is bound to bring questions my way wondering what does that SHOULD *really* mean?. If that were to happen, the only ethical thing to do would be to refer the question to Mark Nottingham. I've begun training an email filter to forward questions to him ;) That is not a problem worth creating in return for advocating the type of feed we think is cool right now. Robert Sayre
Re: PaceOptionalSummary
I'll +1 on MAY. On 27 Apr 2005, at 04:29, Robert Sayre wrote: 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 making up requirements to add to the spec. This is over and its a waste of the WG's time. Let me summarize: MUST: Sam SHOULD: Graham, Roger Eh: Bill MAY: Myself, James T, Antone, Eric, Julian, Martin, Aristotle Robert Sayre
Re: PaceOptionalSummary
One reason for title only feeds is to address bandwidth limited devices. The server I set up provides the same feed in two different formats - one title only and the other with title/summary/etc. The end client can decide which feed it wants to work with based on its capabilities; however, both feeds need to be Atom spec compliant. The only thing needed for interop is some minimal useful information to indicate what the entry is (Title), the ID to identify uniqueness and a time stamp (updated) to indicate time ordering. Everything else simply adds more richness to the entry; some may be used by the end client and some may not. For example, sending entries with summarys may not be of any value to a device with limited display/storage capabilities, so why require it when it only chews up transmission bandwidth? Brett Lindsley, Motorola Labs.
Re: PaceOptionalSummary
On Wed, 27 Apr 2005 06:35:21 -0400, Sam Ruby [EMAIL PROTECTED] said: While I agree that the implications of a decision to omit a summary need to be understood and carefully weighed by the feed author, I don't believe that mandating the summary element actually achieves this So.. can we agree on SHOULD? Well, given how close what I've said I agree to is to the wording of RFC 2119, I'll look inconsistent if I don't say 'yes' :-) I could certainly live with SHOULD. James -- James Tauber http://jtauber.com/ journeyman of somehttp://jtauber.com/blog/
Re: PaceOptionalSummary
* Sam Ruby [EMAIL PROTECTED] [2005-04-27 12:45]: So.. can we agree on SHOULD? +1. My previous tentative +1 for MAY is hereby withdrawn. Regards, -- Aristotle
Re: PaceOptionalSummary
I used title=titles and title=full to indicate the varients in the feed discovery while maintaining compliance with the current spec. The user must select which feed to use. One assumption I am making is that the updated time for both the title only and the full entry are the same. If I have a title only entry and I want the full entry, I just use the updated time to indicate a time range in the full entry feed. I also use the same ID and verify the returned full entry matches the ID of the title only entry. Brett Lindsley, Motorola Labs Antone Roundy wrote: On Wednesday, April 27, 2005, at 04:21 AM, Brett Lindsley wrote: One reason for title only feeds is to address bandwidth limited devices. The server I set up provides the same feed in two different formats - one title only and the other with title/summary/etc. The end client can decide which feed it wants to work with based on its capabilities; This raises a few questions: 1) How does one indicate the existence of variants? 2) Can/should the variant feeds use the same atom:ids for variants of the same entries? 3) How does a client select a preferred variant? 4) How does an aggregator discover the complete and/or authoritative variant of an entry? Here's a quick idea for how this might be done. Especially at this late stage, this would almost certainly go in an extension. But I bring it up now because of the issue raised by question #2 could mean that the extension MIGHT be contradicting the Atom spec if it said to use the same atom:id for multiple variants, depending on one's interpretation: feed link rel=variants ... /!--this is a link to a file listing variants-- link rel=complete ... /!--this is a link to a variant which contains all of the elements found in any variant--it's conceivable that no such variant may exist in some cases--they might just be alternatives--or there could be more than one--thus this concept may not be useful-- link rel=authoritative ... /!--this is a link to the feed that the publisher considers to be the authoritative version from which the others are derived-- ... /feed variants xmlns=... variant href=...!--the entries in this variant contains the following elements...-- elemtitle/elem elemid/elem elemupdated/elem elem[EMAIL PROTECTED]alternate]/elem /variant variant href=...!--this could be complete-- elemtitle/elem elemid/elem elemupdated/elem elem[EMAIL PROTECTED]alternate]/elem elem[EMAIL PROTECTED]html]/elem /variant variant href=...!--this also could be complete-- elemtitle/elem elemid/elem elemupdated/elem elem[EMAIL PROTECTED]alternate]/elem elem[EMAIL PROTECTED]xhtml]/elem /variant /variants
Re: PaceOptionalSummary
On 28/4/05 12:10 AM, Antone Roundy [EMAIL PROTECTED] wrote: feed link rel=variants ... /!--this is a link to a file listing variants-- link rel=complete ... /!--this is a link to a variant which contains all of the elements found in any variant--it's conceivable that no such variant may exist in some cases--they might just be alternatives--or there could be more than one--thus this concept may not be useful-- link rel=authoritative ... /!--this is a link to the feed that the publisher considers to be the authoritative version from which the others are derived-- ... /feed why not feed link rel=alternate type=application/xml+atom title=minimal/ link rel=alternate type=application/xml+atom title=authoritative/ link rel=alternate type=application/xml+atom title=summmaries/ ... /feed and the client agent can then present these to the user to select from. e.
Re: PaceOptionalSummary
On Wednesday, April 27, 2005, at 08:53 AM, Eric Scheid wrote: why not feed link rel=alternate type=application/xml+atom title=minimal/ link rel=alternate type=application/xml+atom title=authoritative/ link rel=alternate type=application/xml+atom title=summmaries/ ... /feed and the client agent can then present these to the user to select from. At present: atom:feed elements MUST NOT contain more than one atom:link element with a rel attribute value of alternate that has the same type attribute value. ...but if that were something other than alternate... The question is, do you want this to be automatically discoverable or only user selectable? Finding the authoritative variant automatically might be important for some applications. Finding a variant with a specific set of elements and as few others as possible might be important for other applications. That COULD be done by downloading and inspecting each variant. ...but I'm really speculating here. The main reason I brought this up now was because, given that some people are already publishing variant feeds, it might be good to answer the question of whether using the same atom:id in variants of an entry is legal, and if so, how such things should/could be handled.
Re: PaceOptionalSummary
Walter Underwood wrote: I'm not being entirely silly here. We could distinguish between I am not providing a summary (no element) and the summary is void (empty summary). +1 This means I agree with Rob that these [1] three entries mean different things. [1] http://www.imc.org/atom-syntax/mail-archive/msg14432.html -- Thomas Broyer
Re: PaceOptionalSummary
Thomas Broyer wrote: Antone Roundy wrote: This raises a few questions: 1) How does one indicate the existence of variants? [EMAIL PROTECTED]alternate or using a custom (read: extension) relations or using extension elements. See also my comments below on 3). I'll just stop lurking for a minute to make the following suggestion: Why do you not simply follow the lead of HTML [1] on this issue, which uses a list of values--to express, e.g., [EMAIL PROTECTED] alternate stylesheet? So maybe something along the lines of [EMAIL PROTECTED]alternate summary could work for Atom, too. Regards, Andreas [1] http://www.w3.org/TR/html4/types.html#type-links
Re: PaceOptionalSummary
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 inappropriateness and steamrolling. That encourages me to stay neutral. The absence or otherwise of atom:summary causes no interoperability problems for that protocol; HTTPLR agents are not licensed to process summaries. The use of Atom in HTTPLR is arguably not a common usecase (today at least). Of the people I know implementing it, atom:summary has not come up as an issue. It appears to make no odds one way or another if atom:summary there or not empty or not. Finally please note that HTTPLR is different from the other cases cited which might or might not be relevant to the IESG and ATOMPUB. First, it's a protocol, not a website. Second, it's not gone through the IETF process a la APP, though it will appear as an I-D around June of this year. cheers Bill
Re: PaceOptionalSummary
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 point. Suppose we leave it the way it is... people who don't want to include a summary can use summary/, so it's just silly to say that there's an example of a current feed that would be ruled out. For that matter, Graham's body-only feeds can be done with title/. I can see Sam's arguments, but on the other hand, the errors that might get caught by requiring summary are probably boring corner-cases anyhow. Which is to say, it doesn't matter very much. Which is to say, 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. -Tim 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. And we have the experience from RSS 2.0 (motto: everything is optional! and extensible!) whereby Don Box introduced xhtml:body into his feed in place of description, something that most aggregators support today. On the other hand, what we have is arguments that entries with empty summaries is not possible with the current format - something that is blatantly incorrect. We also had a very complex and delicate negotiation a while back that seems to have been forgotten. It is quite possible to produce feeds with content that is base64 encoded binary or out of band. What is desired in such circumstances is precisely akin to specifications that require alt attributes for img tags. It atom's case, it is a summary. If you want to push through this pace, I suggest that we revisit and reopen those discussions. Schedule be damned. - Sam Ruby
Re: PaceOptionalSummary
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? What does that have to do with interop? And we have the experience from RSS 2.0 (motto: everything is optional! and extensible!) whereby Don Box introduced xhtml:body into his feed in place of description, something that most aggregators support today. Yes, and he just might stick xaml:body in there next year. We can't stop him. On the other hand, what we have is arguments that entries with empty summaries is not possible with the current format - something that is blatantly incorrect. Well, the argument was originally that people don't like title-only feeds, so we shouldn't even worry about them (see journalist point above). We also had a very complex and delicate negotiation a while back that seems to have been forgotten. It is quite possible to produce feeds with content that is base64 encoded binary or out of band. What is desired in such circumstances is precisely akin to specifications that require alt attributes for img tags. It atom's case, it is a summary. I've edited Tim's Pace to show what the resulting text would look like, since a summary would still be required in such circumstances. Hopefully, the resulting requirements are clear now. Robert Sayre
Re: PaceOptionalSummary
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 summary/ meaning no summary would not see any reason to make it optional. James -- James Tauber http://jtauber.com/ journeyman of somehttp://jtauber.com/blog/
Re: PaceOptionalSummary
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
Re: PaceOptionalSummary
Do the following messages mean the same thing? Robert: In my app? Yep, exactly the same. -- Roger Benningfield
Re: PaceOptionalSummary
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 I'll just do what I already do with title-only RSS feeds... have my code reject them as inadequate. Just like it would reject an entry containing summary/, since it means the same thing, right? You yourself send them: http://www.imc.org/atom-syntax/mail-archive/msg14147.html They are clearly adequate for some class of applications, so please demonstrate the interoperability problems they cause. Robert Sayre
Re: PaceOptionalSummary
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 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 wouldn't under Tim's proposal), my app can't reliably interoperate with yours. (Why does my app need to know? None of our business) Graham
Re: PaceOptionalSummary
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 wouldn't under Tim's proposal), my app can't reliably interoperate with yours. What if you get this: entry idwhetever/id titleSo Caleb is Lindsey's father/title summaryDNA testing has proven Caleb is Lindsey's father/summary /entry What does this mean? a) a title and summary only entry b) a full content entry with the content missing c) a summary and extension element entry with dc:modified missing etc. etc. etc. As long as an entry meets the requirements of the spec, if an element isn't there, the consumer (unless it has some special out-of-band knowledge) has to assume that the entry is complete. If anything that the publisher intended to have there is missing, then their software has a bug or they've misconfigured it, and ensuring that their buggy or incorrectly configured software interoperates well is beyond the scope of the spec, is it not?
Re: PaceOptionalSummary
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 No? Interoperate with what? If I write an app that needs to know whether an entry had a body that was removed or is a title-only feed, it cannot interoperate with Atom feeds under Tim's proposal because there is no difference between them. This is totally an interoperability issue. Graham
Re: PaceOptionalSummary
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 is totally an interoperability issue. Nonsense. None of Atom's elements communicate that information, and there is no requirement to do so. Next. Robert Sayre
Re: PaceOptionalSummary
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 interoperate? Yes or No? Interoperate with what? If I write an app that needs to know whether an entry had a body that was removed or is a title-only feed, it cannot interoperate with Atom feeds under Tim's proposal because there is no difference between them. This is totally an interoperability issue. I'm not sure what you're saying is sensible. If you wrote that app, you've gone beyond anything Atom format mandates. Getting on board with your app would induce bug compatability, not interop. cheers Bill
Re: PaceOptionalSummary
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 purposes. No aggregator *requires* a date... if one's not attached, we can just slap on the date we acquired the entry. And so on... I honestly can't think of a single child of atom:entry that is required for interop. In which case, the only MUST in the spec would be atom:entry MUST contain at least one child element of some kind. Have fun with that. No one needs Atom for producing a title-and-link feed. It's overkill, and pointless. The juice in Atom is in the handling of content... providing for explicit summaries, and clearly defined payload types. -- Roger Benningfield
Re: PaceOptionalSummary
* 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 minimum atom:entry (with an atom:id, atom:title, and atom:[EMAIL PROTECTED]'alternate']). Near as I can tell, there is no discernible difference between an empty and an absent summary (given the presence of the mandatory other information!). Tentatively +1. I also suggest that any cogent explanation would need to be put on record in the spec, to alert implementors to the issues and guide them to an educated choice. Otherwise, they are likely to disregard this issue either wilfully or out of negligence. Regards, -- Aristotle
Re: PaceOptionalSummary
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. It's overkill, and pointless. The juice in Atom is in the handling of content... providing for explicit summaries, and clearly defined payload types. The juice in Atom has little to do with the syndication format. IDs and dates are big, though. Robert Sayre
Re: PaceOptionalSummary
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 absent. The pace as written newly allows the omission of a summary and content on the whim of the publisher. It also allows its omission when the content of the entry has been placed in a non-atom container. My first problem is that neither of these consequences seem intended. My second is that it is the interopability issue. I'm within my rights as a consumer to reject title-only feeds as not worth bothering with (before you condemn this as an arbitrary decision, bear in mind the current Atom spec makes the same judgement). The atom spec would not give publishers fair warning of this. This is why I think it makes more sense as a SHOULD requirement. (btw The list of scenarios reprinted in the Pace doesn't mention whether you MAY include atom:summary outside the MUST cases) Graham
Re: PaceOptionalSummary
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 content is absent. The pace as written newly allows the omission of a summary and content on the whim of the publisher. It also allows its omission when the content of the entry has been placed in a non-atom container. My first problem is that neither of these consequences seem intended. My second is that it is the interopability issue. I'm within my rights as a consumer to reject title-only feeds as not worth bothering with (before you condemn this as an arbitrary decision, bear in mind the current Atom spec makes the same judgement). The atom spec would not give publishers fair warning of this. This is why I think it makes more sense as a SHOULD requirement. Well stated. I'd also add that apparently summary SHOULD be non empty in all of the cases where it is currently required as well as one new case: the case where the content is empty. - Sam Ruby
Re: PaceOptionalSummary
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 condemn this as an arbitrary decision, bear in mind the current Atom spec makes the same judgement). It is arbitrary. My point is that the spec does not reflect consensus in this working group or help interop. You're within your rights to reject anything, you just want the spec to back you up, and that's ridiculous. The atom spec would not give publishers fair warning of this. This is why I think it makes more sense as a SHOULD requirement. Well stated. I'd also add that apparently summary SHOULD be non empty in all of the cases where it is currently required as well as one new case: the case where the content is empty. Nonsense. Never. There are plenty of people here disagreeing with you. Robert Sayre
Re: PaceOptionalSummary
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 making up requirements to add to the spec. This is over and its a waste of the WG's time. Let me summarize: MUST: Sam SHOULD: Graham, Roger Eh: Bill MAY: Myself, James T, Antone, Eric, Julian, Martin, Aristotle Robert Sayre
Re: PaceOptionalSummary
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 you condemn this as an arbitrary decision, bear in mind the current Atom spec makes the same judgement). It is arbitrary. My point is that the spec does not reflect consensus in this working group or help interop. You're within your rights to reject anything, you just want the spec to back you up, and that's ridiculous. The atom spec would not give publishers fair warning of this. This is why I think it makes more sense as a SHOULD requirement. Well stated. I'd also add that apparently summary SHOULD be non empty in all of the cases where it is currently required as well as one new case: the case where the content is empty. Nonsense. Never. There are plenty of people here disagreeing with you. If you attempt to syndicate a contentless and summaryless entry, there will be people who drop it on the floor. It doesn't matter how many people write software that behaves otherwise, it is a reality that some will behave this way. From RFC 2119: SHOULD This word, or the adjective RECOMMENDED, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I am willing to concede that there are valid reasons in particular circumstances to ignore the requirement for a summary. Are you willing to concede that there are implications to such a decision that must be understood and carefully weighed before chosing to omit a summary? - Sam Ruby
Re: PaceOptionalSummary
I would much prefer changing the MUST to a SHOULD rather than dropping the requirement completely, which would achieve the same goal. I don't believe requiring at least a summary is an unfair baseline requirement in other use cases. (btw I also think there's an equally valid use-case for body-only feeds) Graham On 25 Apr 2005, at 7:25 pm, Tim Bray wrote: re constructive than whatever the hell that was. What Rob wants is what he said in http://www.imc.org/atom-syntax/mail-archive/msg14157.html I decided it would help if there was an actual Pace: http://www.intertwingly.net/wiki/pie/PaceOptionalSummary
Re: PaceOptionalSummary
Tim Bray wrote: On Apr 25, 2005, at 11:01 AM, Graham wrote: Can you post some links to examples of feeds you think are difficult to express in the current syntax? That would be considerably more constructive than whatever the hell that was. What Rob wants is what he said in http://www.imc.org/atom-syntax/mail-archive/msg14157.html I decided it would help if there was an actual Pace: http://www.intertwingly.net/wiki/pie/PaceOptionalSummary -1 Steamroll over me and others if you must, but I believe that title only feeds are more often that way due to an error of omission than by an explicit design choice. Enough so that it warrants someone explicitly saying this summarly intentionally left blank, thus: summary/ Given a way to express an intentional omission of a summary, this discussion changes from a discussion of use cases that allegedly are not supported, to one of whether tools like RNG grammars and feedvalidators can assist people who produce feeds in making their intents clear. - Sam Ruby
Re: PaceOptionalSummary
On 4/25/05, Julian Reschke [EMAIL PROTECTED] wrote: Tim Bray wrote: I decided it would help if there was an actual Pace: http://www.intertwingly.net/wiki/pie/PaceOptionalSummary It doesn't make sense to REQUIRE protocol elements for which there are valid reasonable use cases where implementations can't supply them and which aren't absolutely needed for interoperability. This Pace addresses my concerns in full. Robert Sayre
Re: PaceOptionalSummary
On Monday, April 25, 2005, at 12:25 PM, Tim Bray wrote: I decided it would help if there was an actual Pace: http://www.intertwingly.net/wiki/pie/PaceOptionalSummary +1
Re: PaceOptionalSummary
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 point. Suppose we leave it the way it is... people who don't want to include a summary can use summary/, so it's just silly to say that there's an example of a current feed that would be ruled out. For that matter, Graham's body-only feeds can be done with title/. I can see Sam's arguments, but on the other hand, the errors that might get caught by requiring summary are probably boring corner-cases anyhow. Which is to say, it doesn't matter very much. Which is to say, 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. -Tim
