Re: Query re: support of Media RSS extensions inside Atom feeds
On Feb 9, 2007, at 9:23 PM, John Panzer wrote: Does anyone know of any issues with placing Yahoo! Media RSS extensions (which seem to fit the requirments for Atom extensions to me) inside an Atom feed? Secondarily A year or two ago there was discussion of doing an IETF working group to add Media RSS (or equivalent) extensions to Atom. Is there any interest in reviving that effort? -- Ernie P. On Feb 10, 2007, at 10:51 AM, Antone Roundy wrote: , do feed readers in general recognize MRSS inside either Atom or RSS? Looking for field experience/implementor intentions here. CaRP partially supports Media RSS in RSS (it doesn't directly support Atom at all, and Grouper, the companion script that converts Atom to RSS for it doesn't yet have Media RSS support, though I may add it in the next update). It only looks at elements pointing to images (@type=image/*) and their types, heights and widths. I added this in response to user requests--primarily, I believe, for use with Flickr feeds. Antone
Re: Atom Entry docs what Bob said
yeah what Bob said I'm not sure it is ideal, but it seems the closest to consensus we're ever going to get. +1 On Dec 14, 2006, at 7:08 AM, Rogers Cadenhead wrote: --- Bob Wyman [EMAIL PROTECTED] wrote: 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get them defined, registered, and ready to use.) 2) Leave RFC4287 unchanged. i.e. do NOT re-define application/atom-xml 3) New specifications MAY require that ;type=entry be used. (Note: Just because ;type=entry is used DOES NOT imply that ;type=feed must also be used) +1 on this approach. RFC4287 is a powerful argument in Atom's favor. Chip away at that spec and we're going to start hearing from Mr. Safe again.
Re: Atom Entry Documents
On Dec 10, 2006, at 11:19 AM, James M Snell wrote: Option B) New Entry media type application/atom.entry+xml +1 I presume the whole reason we need this is that *existing* parsers are blindly assuming that application/atom+xml means a feed document. If that is an invalid assumption, then I think (B) is the way to go. If not, them I'm unclear what the problem is. -- Ernie P.
Re: PaceEntryMediatype - rel-type instead
On Dec 1, 2006, at 10:42 AM, Kyle Marvin wrote: I see the separation but I'm still missing a clear justifiication for it. I don't see content-type as having anything to do with the audience. It's about what media format you'd get back if you dereference the href and rel is about how you can interpret/ interact with it. I feel like the primary audience for content- type is likely to be used in selecting some type of parser when retrieving the resource. Orthogonal to this, the rel value assigns some semantic meaning to the resource (what does the entry or feed describe) and might also specify what interaction model you might expect via the href (ex. edit implies APP edit semantics on an entry resource). +1 to what Kyle said -- Ernie P.
Re: PaceEntryMediatype
Hi James, On Dec 1, 2006, at 11:25 AM, James M Snell wrote: You're right that the differentiation in the content-type is of less importance but without it there's no way for me to unambiguously indicate that a resource has both an Atom Feed representation and an Atom Entry representation. The best I could do is say This things has two Atom representations. Keep in mind that I want to be able to differentiate the types of alternate representations available without having to look at any of the other rel keywords. I understand that this is *what* you want, but I'm still unclear why. From where I sit, Kyle's argument makes sense: keep the syntax in content-type, and the semantics in rel-type. This seems both simpler and more consistent with how the web works today. No? Or is there some overriding reason for ignoring rel-type? -- Ernie P.
Re: PaceEntryMediatype - Options
Hi Antoine, On Nov 30, 2006, at 10:21 AM, Antone Roundy wrote: Summary of thoughts and questions: Thanks -- this is incredibly helpful. However, might I suggest a couple more options? 6) Change expectations, not the spec. Consumers must poll the feed to inspect the metadata, and Servers must accept both. 7) Disallow entry-only documents Require all Atom documents to have a feed wrapper in order to be parsed properly. This is basically #4 + procrastination. :-) I'm not saying these are necessarily _good_ options, but I'd like to be sure that whatever we do propose is superior to either of these; i.e., is the use of entry-only documents important enough to justify all this work? Thanks, -enp *** Problems with the status quo *** A) Consumers don't have enough information (without retrieving the remote resource) to determine whether to treat a link to an Atom document as a link to a live feed, a feed archive, or an entry. (Is it appropriate to poll the link repeatedly? How should information about the link be presented to the user?) B) APP servers can't communicate whether they will accept feed documents or only entry documents. *** Possible solutions *** 1) Add a type parameter to the existing media type: + With the exception of a few details, the documents are all exactly the same format (does it contain a feed element, or does it start at the entry element, is it a live feed document or an archive, etc.), so a single media type makes the most sense (definitely for live feeds vs. archives, less certainly for feeds vs. entries). - Some existing applications will ignore the parameter and may handle links to non-live-feeds inappropriately - Some existing applications may not recognize application/atom +xml;type=feed as something appropriate to handle the same way they handle application/atom+xml now. ? I haven't been following development of the APP, so forgive my ignorance, but can parameters be included in the accept element? 2) Create (a) new media type(s) (whether like application/atomentry +xml or application/atom.entry+xml): + Applications that currently treat all cases of application/atom +xml the same would ignore non-feed links until they were updated to do something appropriate with the new media type. - Differentiating between live feeds and archives by media type seems really wrong since their formats are identical. This isn't as big a negative for entry documents, but it still seems suboptimal to me. - If a media type were created for archive documents, would APP accept including application/atom+xml imply acceptance of archive documents too? Neither yes nor no feels like a satisfying answer. 3) Use @rel values to differentiate: - That territory is already a bit of a mess, what with feed vs. alternate vs. alternate feed vs. feed alternate -- why make it worse? + That territory is already a bit of a mess, what with feed vs. alternate vs. alternate feed vs. feed alternate -- why not work on all these messy problems in the same place? - That wouldn't help with the APP accept issue. 4) Create a new media type for entry documents, and add a parameter to application/atom+xml to differentiate between live and archive feeds (and for any other documents that have the identical format, but should be handled differently in significant cases). - Doesn't prevent existing apps that ignore the parameter from polling archive documents. + Does solve the rest of the problems without the negatives of #2 above. 5) Create a new media type for entry documents, and use @rel values to solve issues that doesn't solve: +/- Messy territory If we were starting from scratch, I'd probably vote for #1. Since we're not, I'd vote for #4 first, and perhaps #5 second, but I'd have to think about #5 more first. Antone
Re: How to do RESTful SEARCH (was Re: Adding POST capability to atom:link)
A server that instead provides light-weight query interfaces as you describe, or guides the client into the content, does not work with a client that doesn't do HTML (a CalDAV, WebDAV or possibly Atom authoring client); correct?My understanding (for what it is worth) is that REST *requires* hypermedia. Your choice of hypermedia then constrains your problem domain. Once you select a domain (HTML, Atom, whatever), then to be RESTful it is important give clients within that domain a way to discover the appropriate syntax using hypermedia.It sounds like you're asking about the protocol independent of how it is presented on the Web. In that case, I think it is fine to say that, e.g., SEARCH *can* be used RESTfully, but I don't think it is *necessarily* RESTful unless we know the rest of the application.My $.02.-enpOn Nov 2, 2006, at 12:06 PM, Lisa Dusseault wrote:On Oct 26, 2006, at 1:02 PM, Jan Algermissen wrote:If you aim to provide a REST interface, do not mimick a query interface (at least not a complex one). Think of your 'asset space' in terms of pre-defined, useful collections that you expose as resources (feeds) and provide light weight query interfaces to them that fit with GET requests.Think in terms of browsing and drilling-down; REST interfaces guide the client into the content instead of assuming the knowledge to constructa query does reside in the client.This is an interesting assertion about REST. I don't yet agree with it as stated though I might after further discussion and elaboration. To provide a possible counter-example, I always found the HTTP SEARCH proposal http://www.greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html to be RESTful because - The results of a search are returned as a set of resource identifiers - It doesn't necessarily break for dynamic resources as long as the server can handle that - It doesn't break the layering of representations, or use of connectors, or caching of resources - It's general -- can be used for WebDAV resources but also for any HTTP server, CalDAV resources or probably (with some thought) Atom resourcesA server that instead provides light-weight query interfaces as you describe, or guides the client into the content, does not work with a client that doesn't do HTML (a CalDAV, WebDAV or possibly Atom authoring client); correct?Lisa
OT Re: [OFF-LIST] Re: Fwd: Link rel test cases [OFF-LIST]
Hi Robert, While I'm not entirely thrilled with James, and I believe you provide some useful perspective, if you think it is appropriate and ethical to respond by posting private email to the list, I must reluctantly conclude that this list is better off without you. Sincerely, Ernest Prabhakar On May 30, 2006, at 7:25 PM, Robert Sayre wrote: Hmm, do you harass everyone who disagrees with you like this? I am kind of taken aback by this unprofessional conduct. I don't see how I am supposed to participate in an IETF working group if the document authors are going to engage in this kind of vitriol. I wonder if you think it's ok to write this kind of thing in private email. I'm disappointed. :/ On 5/30/06, James M Snell [EMAIL PROTECTED] wrote: [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] Had I meant to cc the list, it stands to reason that I would have cc'd the list. I've grown quite tired of this Insult-James-And-Everything-He-Does-And-Says campaign of yours. You are accomplishing nothing. Get a life and move on. - James [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] [OFF-LIST] Robert Sayre wrote: I think James forgot to cc the list -- Forwarded message -- From: James M Snell [EMAIL PROTECTED] Date: May 30, 2006 9:38 PM Subject: Re: Link rel test cases To: Robert Sayre [EMAIL PROTECTED] Robert Sayre wrote: [snip]...have James add it to his revision of 4287. :) Pardon, what the hell are you talking about? Do you really, honestly believe that being a complete ass is a productive use of anyone's time? - James -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Feed Thread in Last Call
I've had a hard time following this thread, but for what its worth I buy Tim's reasoning. +1 On May 23, 2006, at 12:26 PM, James M Snell wrote: +1. What Tim said. - James Tim Bray wrote: On May 18, 2006, at 6:15 AM, David Powell wrote: What I see as a problem is that reasonable implementations will not preserve Atom documents bit-for-bit, so they will need to explicitly support this draft if they don't want to corrupt data by dropping the thr:count attributes. By the letter of RFC4287 there is no problem with the draft, but practically there is something like a layering concern if an extension requires existing conformant implementations to be changed. At the end of the day, the marketplace will work within the constraints of what 4287 allows; my feeling is that there are going to be a ton of extensions that will attach unforeseen metadata at arbitrary points with Atom documents, and implementations that fail to store these and make them retrievable will quickly be seen as broken. -Tim I notice that you said implemented support - that is fine for user-agents etc, but I don't believe that Atom infrastructure should be required to implement support for each new bit of content that publishers put into their feeds. On the contrary; I think that implementors who fail to deal with the fact that people will be adding their own non-Atom stuff at every conceivable place in an Atom feed are being very stupid, because this will happen whatever we say. -Tim
Re: Atom, files and directories: what it's all about
Hi Henry, On Nov 23, 2005, at 3:22 AM, Henry Story wrote: A few improvements of atom over directories is that our feed can contain not just the current version of an entry, but all previous versions as well, which I think I remember was a feature supported by the vms file system. Interesting. It reminds me of a thought I had a while ago: would it be possible to emulate 80% of WebDAV by using HTTP + Atom? Would we also need some sort of list structure, a la XOXO? http://microformats.org/wiki/xoxo -- Ernie P.
