On Fri, Jun 5, 2009 at 9:47 PM, Mark Nottingham <[email protected]> wrote:
> Just checking -- you do realise I'm suggesting it's worth using a new media > type for the atom document that contains these extensions, not a new media > type in it? Your response was worded in such a way that I'm not sure... Yes, I understand. I think there are issues with media type under-use at both levels (document and content). There are definitely cases where a new MIME type on the Atom document would be helpful to processors and others where more judicious usage of specialized MIME types for atom:content would be helpful. Let me see if I can give you an example and see if you agree or disagree. Take the case of a feed that describes a calendar and contains entries that describe events in the calendar. If this had a MIME type of something like "application/calendar+atom+xml", then it would might inform a client processing it that there are other possible processing options besides regular syndication, like importing to a local calendar. Such a MIME type might explain the set of metadata extensions specific to calendars that are expected (ex timezone info) and possibly even put constraints or expectations on the MIME type of atom:content found within the entries. Of course, the "application/calendar+atom+xml" is fictitious because there's no model for saying that something is an atom feed of a specific type in the same way that "application/atom+xml" says that it's an XML document with Atom syntax constraints. Rooted in this might be Nikunj's concern but there's probably more (see next paragraph). Without a model for defining Atom media subtypes, you'd have to type it as something that is going to cause a generic Atom processor to ignore it even though it could still be processed in useful (albeit less vertical way) to let me know when data/events are available or have changed via a feed reader interface. I don't know, though, that anything in the hierarchy proposal justifies a new MIME type and given that you say it might be worth *considering* I'm not sure you see it that way either. There are definitely cases where you're just adding extensions that are informative and additional metadata and I don't think these alone define a new data format that needs a media type. Media RSS is possibly another example. Consider these the Atom Syntax equivalent of a ""mixin". If such extensions are standardized and/or get enough de facto usage lots of Atom processors are likely to handle them just fine. So the current proposal is perhaps not the best poster child for using media types more but I definitely think it's something that the Atom community should consider to better enable client use cases in addition to reader-based syndication. All this being said, I think the right venue for creating more specialized Atom media types is in communities that would benefit from their existence and the collaboration or processing models that would be enabled by them. Just minting new MIME types because you've extended Atom is not all that helpful in the bigger scheme of things, imo. HTH, -- Kyle > > > Cheers, > > > > On 06/06/2009, at 3:32 AM, Kyle Marvin wrote: > > On Fri, Jun 5, 2009 at 12:05 AM, Mark Nottingham <[email protected]> wrote: >> >> >> On 05/06/2009, at 2:10 PM, Peter Keane wrote: >> >> I hope I'm not too far off w/ this, but it seems to me there are a >> couple distinct concerns in this thread: First is a need for what is >> essentially multiple atom:content elements in an entry. atom:link >> seems like a logical home for that content (given that we can assign >> an appropriate @rel). >> >> Peter, I'm not sure I see the need like this; you want more than multiple >> content items. What you have here is multiple resources (some of which >> might be metadata + content, i.e. an atom entry, or might not even be Atom >> at all) with some type of relationship between them *and* the desire to >> retrieve these multiple related resources using a single GET. A key >> difference between 'content' and a 'resource' is that the latter is >> independently dereferencable whereas the same isn't necessarily true for any >> atom:content types other than out-of-line-content. A link has the nice >> property of having a rel that describes how it is related to what it is >> contained within (i.e. why it might be referenced), a type attribute that >> informs how to process it (either when referenced or potentially inline), >> and a href that says where to deference it (i.e. how to reference it >> independently even if it is inline). All nice and useful properties within >> the composite resource that allow it to be used in a decoupled fashion after >> the initial GET of the composite resource. >> >> >> >> Well, the most straightforward way to fix that would be to fix Atom and >> allow multiple atom:content elements in an entry... >> >> >> I'd agree with Nikunj that this is not so dramatic a change that new >> media types need to be considered. It feels more like a tweak to me, >> and I do not see much difficulty at all in using my current tools for >> parsing or producing such atom documents. >> >> I think this is valid but an orthogonal concern. The key point is that >> you want to nest a resource that itself has a MIME type and can be >> processed. Whether these are new or existing MIME types depends on the use >> cases and what is the most appropriate MIME type for that relationship. >> >> >> Ah, maybe that's where the misunderstanding lies. It's not that you can't >> parse it with an Atom library, with appropriate code to handle the >> extensions; that's obviously possible. >> >> My concern is that a *generic* Atom processor (e.g., a feed reader) or >> more importantly a generic MIME dispatcher (e.g., a browser or an OS) >> wouldn't be able to do much that's useful with such a feed, because -- as I >> understand the use cases -- most of the information will be in extensions >> that the generic processor won't be able to take advantage of, and because >> the generic MIME dispatcher won't know to send this document to a handler >> that can do something with it. >> >> It might surprise you but I'd agree that using MIME types more would be >> goodness. It's frequently the case (including in GData) that the lines >> between what is metadata and what is content are being blurred since both >> are found in Atom extensions. This fact does make life harder for Atom >> processors, since they have to rely on sideband signals (a 'kind' or a >> 'type') that inform them about what extensions to expect and what they mean >> and there's not much standardization happening in this space. >> >> >> >> This is the role media types play on the Web (and elsewhere, of course)... >> >> I don't know, though, that this is a problem the Atom WG (or a derivative >> effort) can solve. In most cases, those MIME types for nested content are >> domain-specific representations that are best standardized by (or at least >> generally agreed upon) by groups working in that domain. I don't see a >> proliferation of vendor-specific media types as being much better than the >> status quo other than that they'd let you write vendor-specific MIME >> processors; better structured from an Atom perspective but not really >> pushing the Web forward in the right direction from a collaborative >> perspective. >> >> Let me know if you think I'm missing something! >> >> -- Kyle >> >> >> >> Cheers, >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> > > -- > Mark Nottingham http://www.mnot.net/ > >
