> > 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 ? 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"). Hadrien
