[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Atom Inlining (Was Link Extensions. Need "md5" or some kind of hash.)
Non-Atom type support, I think, is definitely important. I also urge
you to consider defining the element so that it is a part of the Atom
namespace. Explosion and management of extension namespaces is going
to become a significant problem as time goes on, we need to establish
good practices for it now.
On Tue, May 18, 2010 at 12:46 PM, Nikunj Mehta <nikunj@xxxxxxxxxxxx> wrote:
> I can brush up the I-D and add the non-Atom type support, which was contemplated but waiting for more interest to be put in.
> On May 18, 2010, at 5:23 AM, Colm Divilly wrote:
>> 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 rel="alternate" href="foo" type="image/jpeg">
>>> <data type="encoded">abc...def==</data> <!-- base64 -->
>>> <link rel="alternate" href="foo" type="application/atom+xml">
>>> <data type="markup">
>>> Or something along those lines.
>> +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  (the last published draft restricted the inline content types to atom resources only ), Nikunj care to weigh in?
>> There was some discussion about this a while back: 
>>  http://atom-ext.googlecode.com/svn-history/r9/trunk/draft-mehta-atom-inline.xml
>>  http://tools.ietf.org/html/draft-mehta-atom-inline-01#section-2.1.1
>>  http://www.imc.org/atom-syntax/mail-archive/threads.html#21203
- James Snell