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