Re: Fwd: PaceEntryMediatype
On 12/8/06, James M Snell <[EMAIL PROTECTED]> wrote: I'm fine with the type parameter approach so long as it is effective. By effective I mean: Will existing implementations actually take the time to update their behavior to properly handle the optional type parameter. It would be useful to define better what is meant by "properly handle the optional type parameter." Those that don't understand the parameter should simply continue to operate on the current assumption that they can't really be sure if they are reading a feed or an entry until they read the first few bytes. Those that do understand the meaning of the optional parameter will be writing code in the future and we can hope that if they become aware of the type parameter and decide to care about it, they will have sufficient awareness to do whatever they do in a "proper" manner. The only case where I can see a problem would be those folk who match against the existing media type as an opaque string and don't have any code to handle opional type parameters. Such sloppy code would be broken by the use of the optional type parameters since the presence of the parameter would break the simple string matches used by these coders. However, I must admit that I don't have much sympathy for such folk. Making basic design decisions to adress the concerns of these sloppy folk is something like the old prejudice against using XML attributes since it tended to make it harder to create sloppy, regex based parsers... In any case, the alternative proposal, create a new media type for entries, would tend to confuse people who have their code written properly today --- those whose code understands that the existing atom mediatype can be used for both a feed and and entry. What we would be doing by creating a new media type is break the code of the folk who paid attention to the spec in order to preserve the code of those who didn't read the spec (or those who refused to see Atom as anything other than some twisted form of RSS...) This doesn't make sense to me. We should use the type parameter if anything is changed here. bob wyman
Re: Fwd: PaceEntryMediatype
On Fri, 08 Dec 2006 18:52:05 +0100, James M Snell <[EMAIL PROTECTED]> wrote: I'm fine with the type parameter approach so long as it is effective. By effective I mean: Will existing implementations actually take the time to update their behavior to properly handle the optional type parameter. Seeing how eager most applications have been to implement Atom support, I believe the answer to this question is "yes". I'm optimistic at least. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Fwd: PaceEntryMediatype
Bob Wyman wrote: >[snip] > What you seem to be implying is that the majority of applications > that process Atom Feed documents are not, in fact, supporting extremely > important parts of the atom specification. I believe that any properly >[snip] Not quite. What I'm implying is that not all applications have the need to implement the entire specification. Atom Entry Documents and Atom Feed Documents are each very useful but for different reasons. > constructed Atom Feed parser will contain all the code needed to parse > the most complex Atom Entry document. And, an entry document with an > atom:source is semantically equivelant to an atom:feed with a single > entry... The problem here is that people insist on building Atom > parsers that aren't capable of handling more semantics than legacy RSS. > What we should be doing is encouraging people to exploit Atom and use > its features -- atom:source among others -- that aren't supported by RSS. +1 on all points. > For a parser that properly handles the case of an atom:entry > appearing within atom:feed, it should be trivially simple code to > recognize and handle an entry without a feed wrapper. I think there are > even cases where this makes sense -- and you would even want to > subscribe to such a thing: Trivial, yes. That's not really the issue for me. >[snip] > In any case, while it appears reasonable (and sometimes efficient) > for people to subscribe to Entry documents, I don't think we should do > anything disruptive unless someone can establish actual harm being > caused by the current state of affairs. > The fact that I cannot link to an Atom Entry Document from a browser without it trying (and failing) to process it as a Feed Document is harmful. - James
Fwd: PaceEntryMediatype
On 11/30/06, James M Snell <[EMAIL PROTECTED]> wrote: > The key problem with "application/atom+xml;type=entry" is that at least > one major browser (Firefox 2.0) still treats it as a feed and shows the > "subscribe" link. So while the type parameter is a potentially more > elegant solution, the new media type approach would likely be far less > disruptive. I don't understand the logic behind saying that it would be "far less disruptive" to rely on the type parameter in lieu of creating new media types. Personally, I think the type parameter is the solution to this alleged "problem"... It appears to me that the disruption that would be avoided by orphaning atom entries behind a "weird" new media-type is nothing more than the effort of a minor update in a future revision of Firefox. Prior to that update, behavior would be as it is today and frankly, that isn't a really big problem since, as far as I can see, there haven't been many reports of harm being caused by hordes of people accidently trying to subscribe to atom entries. The issues being discussed in this thread seem to be largely hypothetical at best. Nobody has actually established that any harm is currently being done as a result of the "ambiguity" of having both atom document types share a single atom media type. The discussion would be a great deal more engaging if someone could cite an actual history of issues. Barring discovery of real, pressing problems, I think we should take the more conservative approach of using the disambiguation tools provided by the media-type specification -- i.e. use the type parameter. We've got more important issues to focus on... James suggests: "the type parameter is [a] potentially more elegant solution." Elegance is goodness. Let's insist on elegant solutions in the absence of compelling reasons to be inelegant. bob wyman
Re: Fwd: PaceEntryMediatype
I'm fine with the type parameter approach so long as it is effective. By effective I mean: Will existing implementations actually take the time to update their behavior to properly handle the optional type parameter. - James Bob Wyman wrote: >[snip] > James suggests: "the type parameter is [a] potentially more elegant > solution." Elegance is goodness. Let's insist on elegant solutions in > the absence of compelling reasons to be inelegant. > > bob wyman
Fwd: PaceEntryMediatype
On 12/5/06, James M Snell <[EMAIL PROTECTED]> wrote: Mark Baker wrote: It's just an entry without a feed. You'd use the same code path to process that entry whether it were found in an entry or feed document, right? Not necessarily... The majority of applications that most frequently handle Atom Feed Documents have no idea how to deal with Atom Entry Documents and I would wager that most applications that understand how to process Atom Entry Documents and Atom Feed Documents typically don't fall into the same category as most feed readers. What you seem to be implying is that the majority of applications that process Atom Feed documents are not, in fact, supporting extremely important parts of the atom specification. I believe that any properly constructed Atom Feed parser will contain all the code needed to parse the most complex Atom Entry document. And, an entry document with an atom:source is semantically equivelant to an atom:feed with a single entry... The problem here is that people insist on building Atom parsers that aren't capable of handling more semantics than legacy RSS. What we should be doing is encouraging people to exploit Atom and use its features -- atom:source among others -- that aren't supported by RSS. For a parser that properly handles the case of an atom:entry appearing within atom:feed, it should be trivially simple code to recognize and handle an entry without a feed wrapper. I think there are even cases where this makes sense -- and you would even want to subscribe to such a thing: Consider a "feed" that communicates "current weather" or "current stock price", etc. We wouldn't be surprised if such a "feed" never contained more than a single entry. We also wouldn't be surprised if the publisher of this single entry feed decided that he wanted to sign the entry in this single-entry-feed and was thus forced to insert all of the feed data into the entry's atom:source. Of course, once you've got a single-entry Atom feed which contains a signed entry, you have all the feed data duplicated -- so, it wouldn't be surprising to see authors of such feeds argue that they shouldn't be forced to waste bits on duplicated feed data when an atom entry document provides exactly what they need. In any case, while it appears reasonable (and sometimes efficient) for people to subscribe to Entry documents, I don't think we should do anything disruptive unless someone can establish actual harm being caused by the current state of affairs. bob wyman
