Draft proposal: Indirection for <content>

["John Panzer" <jpanzer@xxxxxxx>]

Proposal:  The
<content> element of <entry> should support a src="" 
attribute.  The value of this attribute is a URL, which points at a
location where the actual data for the content may be found.  If a
content element has a src attribute, it MUST NOT have inline content;
conceptually, the data at the URL provides the complete data for the
entry.

Example: <content
src="" class="moz-txt-link-rfc2396E" href="http://www.example.org/catblog/_resources/catpicture001.jpg">"http://www.example.org/catblog/_resources/catpicture001.jpg"
type="image/jpeg" />

Motivation:
(1) Supports ability to have a picture "be" an entry, with metadata,
but without the overhead of base-64 encoding, and without needing to
wrap it in an otherwise extraneous XHTML body with an <img src>
tag.
(2) Allows feeds to provide an index into content without forcing
clients to download potentially large amounts of data.  Imagine a feed
of all pictures in a blog.
(3) Allows for caching of separately downloaded images, delayed
downloading, etc. -- basically the same advantages of the HTML <img
src> tag.

This assumes that we want to allow <content> to support types
like image/jpeg directly, rather than supporting XHTML which references
the images.  If not, this proposal is probably not needed as XHTML
suffices.

Of course, this also works in conjuncation with Option #1 and Option #6
for separate uploading of binary content.  If you want to do a 'photo
blog' where each entry really is just a picture, this would let you do
that efficiently:  The Atom entry you upload would use <content
src> to reference each photo.  

-John Panzer