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/ > >
