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 <[email protected]> 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. > > Nikunj > 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> >>> >>> <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 >> > > -- - James Snell http://www.snellspace.com [email protected]
