This proposal extends the Atom Syndication Format to allow an atom:entry to refer to its content indirectly, via a @src attribute, rather than inline between <content>...</content>. This is intended to support PaceNonEntryResources, PaceSimpleResourcePosting, or other proposals that require that binary content be referred to indirectly rather than being encoded inline within an atom:entry.
This proposal is an alternative to PaceSimpleContentType, which has as a sub-proposal the addition of a <atom:link rel="content"...> construct to allow for indirect references. The main differences between the two proposals are that this one is concerned entirely with the issue of indirect content, with minimal impact to the Atom Syndication Format, whereas PaceSimpleContentType aims at more sweeping reform. Either proposal will work for PaceSimpleResourcePosting or PaceNonEntryResources.
Additions/modifications to Atom Syndication Format
The following is an alternative to part (2) of PaceSimpleContentType. It provides roughly equivalent functionality if only one atom:content construct is allowed per entry, as PaceSimpleContentType proposes.
3.1.3 "src" Attribute
Content constructs MAY have a "src" attribute, whose value is a URI. When "src" is present, user agents SHOULD treat the resource located by the URI 'as if' it were the content. User agents SHOULD treat the inline text content of the atom:content element only as a fallback, for example if the URI resource is inaccessible. User agents SHOULD indicate to readers that a fallback is being used in this case. User agents MAY choose not to display content for types or URI schemes they do not understand, or hand off responsibility for handling content to some other program (such as a system web browser). Servers SHOULD ensure that the "type" of the atom:content construct and the media type of the content at the "src" URI match. Clients MAY NOT assume that they will always match (the server might do ContentNegotiation on the specific resource).
Clients reading a feed must support the concept of indirect content and may not assume that the feed contains all the desired content. Note that this is already logically the case with the (X)HTML "img src" attribute and the images it references.
Clients posting new entries or editing entries must be prepared to deal with indirect content.
Content indirection is useful for syndication/downloading as well as uploading. For example, it allows caching of potentially large pieces of data.
The "type" attribute of atom:content may be very important if the URI scheme is not "http". For example, "ftp" or "file". (TODO: I am unsure if PaceSimpleContentType addresses this.)