Concrete benefits include being able to specify the media type of the linked resource, as well as take advantage of other extensions such as the Atom Link Extensions I've proposed, and Google's convention of using child elements within atom:link to provide additional metadata such as multiple alternative representations of an image (e.g. thumbnails, etc). At the very least, we should be able to specify the media type of the linked image.
On Wed, Oct 13, 2010 at 10:37 AM, Antone Roundy <[email protected]>wrote: > > I've never been a fan of using <link> for connecting to every sort of > external entity, since it makes it impossible to write general purpose > <link> handling code (for unknown @rel values) without ending up doing > things that degrade the user experience. But that battle has already > been lost (when the idea of reserving <link> for links intended for > traversal was rejected). > > The question now is, what benefit do we get in exchange for > implementations having to be updated to look for the images in a new > location? If there's no concrete benefit, I'd vote for keeping it as > it is. It'll be simpler for new implementers if they don't have to > discover that something in the spec has been deprecated. And it'll be > simpler for everyone if there are fewer ways to do the same thing. > > Antone > >
