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).
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.
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.
This is the role media types play on the Web (and elsewhere, of course)...
Cheers, -- Mark Nottingham http://www.mnot.net/
