Author: JohnPanzer


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.




If either of PaceNonEntryResources or PaceSimpleResourcePosting are adopted, there will be a need to refer to binary resources outside of an atom:entry, in particular for uploading.


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.

(See [WWW]Content Constructs, section 3.1)

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.

This proposal affects implementation of PaceSimpleResourcePosting or PaceNonEntryResources. It is an alternative to (and incompatible with) PaceSimpleContentType.


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.)