Hi Hadrien, On Wed, May 18, 2011 at 03:25:57PM +0200, Hadrien Gardeur wrote: > > > > On reflection, I don't think the link template idea above is a good > > solution, > > because the client has no way of finding out what inline content types are > > available. > > > > I wonder if a better solution would be to invent three new pieces of > > machinery: > > > > * a new @inline-type extension attribute for use on atom:link elements > > > > * a new Accept-Inline HTTP header > > > > * a new <accept-inline> element for use within app:collection elements in > > Atom > > service documents > > > > These are three different problems though... > Erik seems to be strictly interested in solving the first one, and in this > case, would a single attribute with a secondary mimetype be enough ?
Yes, absolutely. I was just thinking that, if you had all three pieces of machinery, then you would have the tools to solve a range or problems all related to encapsulated media types, including Erik's. This might be a reasonable scope for an internet draft, for example. > I don't think that we need a new rel value, or that we should limit this new > attribute to a specific rel either. While you're strictly talking about > alternate versions of the same content, this attribute would also be useful > for other use cases (for example I might publish a music review as an atom > entry, and provide a link@rel="related" with type="application/zip" and > inline-type="audio/mpeg"). Good point. Cheers, Alistair -- Alistair Miles Head of Epidemiological Informatics Centre for Genomics and Global Health <http://cggh.org> The Wellcome Trust Centre for Human Genetics Roosevelt Drive Oxford OX3 7BN United Kingdom Web: http://purl.org/net/aliman Email: [email protected] Tel: +44 (0)1865 287669
