James Snell wrote:
Another change that I am contemplating making is introducing a new
child element for the atom:link element that would allow it to serve
the same basic purpose as the GData feedLink and entryLink elements
except with greater flexibility... specifically, it would allow a
representation of the linked resource to be dropped directly into the
link element, e.g.
<link rel="alternate" href="foo" type="text/plain">
<data type="text">this is a representation of the data</data>
</link>
<link rel="alternate" href="foo" type="image/jpeg">
<data type="encoded">abc...def==</data> <!-- base64 -->
</link>
<link rel="alternate" href="foo" type="application/atom+xml">
<data type="markup">
<feed>...</feed>
</data>
</link>
Or something along those lines.
Thoughts?
+1, I think this is really important, Whenever I am designing resources,
I am always finding myself having to make a choice about whether to
inline related content in the resource or include a hyper link to the
related content. Having a consistent pattern for doing this would be
beneficial.
As an aside, if this approach was possible, then one could re-imagine
the atom:content element as simply <link rel="content">...</link>.
Nikunj Mehta has an unpublished draft of Atom Inline Extensions that
proposes the same as what you propose [1] (the last published draft
restricted the inline content types to atom resources only [2]), Nikunj
care to weigh in?
There was some discussion about this a while back: [3]
[1]
http://atom-ext.googlecode.com/svn-history/r9/trunk/draft-mehta-atom-inline.xml
[2] http://tools.ietf.org/html/draft-mehta-atom-inline-01#section-2.1.1
[3] http://www.imc.org/atom-syntax/mail-archive/threads.html#21203
