Nikunj R. Mehta
2009-06-08 20:44:11 UTC
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 find Kyle's commentary sympathetic to my previous concern.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.
In reviewing an industry specification for content management [1], Ijustifies 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.
came across a situation where additional constraints were placed on a
valid/acceptable Atom entry and it just made me think whether a
generic client can be warned about this through the app:accept kind of
signaling. I recommended that the specification use a media type
parameter for Atom that cautions about the server's expectation about
acceptable content. Since a number of users of Atom feeds beyond
blogging and news frequently require additional markup in Atom
documents, there is a latent interoperability problem with and lack of
adequate metadata about such interactions. Perhaps, a reasoned
approach could be devised to deal with growing use of Atom documents
beyond blogs.
[1] http://www.oasis-open.org/committees/download.php/32668/Draft%2062a.zip
HTH,
-- Kyle-
Cheers,
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
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/
-- Kyle-
Cheers,
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
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/