UserPreferences

PaceFeedsNotCollections


Abstract

Drop list-templates (though that is also proposed separately), drop collections, and just call them feeds.

Status

Withdrawn. See PaceAppFeeds.

Rationale

This approach is known to work.

Proposal

Drop sections 8,9,11, and any relevant part of section 6. Replace as follows:

4. APP Feeds

APP feeds contain primarily textual content. Examples include weblogs, online journals, and wikis.

4.1 GET

Feeds can contain extremely large numbers of resources. A naive client such as a web spider or web browser would be overwhelmed if the response to a GET contained every entry in the feed, and the server would waste large amounts of bandwidth and processing time on clients unable to handle the response. As a result, responses to a simple GET request represent a server-determined subset of the entries in the feed.

An example APP feed:

    <feed xmlns="http://www.w3.org/2005/Atom"   
          xmlns:pub="http://purl.org/atom/app#">
      <title>My Posts1</title>
      <id>urn:uuid:ce61592c-14e2-4557-978e-dfbd444aefa6</id>
      <updated>2005-12-21T04:11:00-08:00</updated>
      <!-- 0 or more atom:entry elements follow -->
      <entry>
        <title type="text">title 25</title>
        <updated>2005-12-21T04:11:00-08:00</updated>
        <author>
          <name>Foo</name>
        </author>
        <summary>It started out looking simple enough...</summary>
        <id>urn:uuid:941e12b4-6eeb-4753-959d-0cbc51875387</id>
        <pub:edit href="./entry7.atom"/>
        <link href="/permalink7.html" />
       </entry>
       ...
    </feed>
Each member entry is represented by an atom:entry element, but those entries are not an editable representation of the entry. To retrieve the source representation of the entry, clients send a GET request to the URI found in each entry's pub:edit element (see Section 4.3.1). Derived resources are located by examining an entry's atom:link elements.

4.2 POST

Clients can add entries to a feed by sending POST requests containing Atom Entry Documents. Some feeds only accept POST requests with certain media-types, so a POST could generate a response with a status code of 415 ("Unsupported Media Type"). The status code returned for a successful creation POST MUST be 201 ("Created").

Example request creating a new entry in a feed:


    ...data... 

Example response.


Existing entries are edited by sending HTTP requests to the URI found in an individual entry's edit link (section xx). Servers can determine the processing necessary to interpret a request by examining the request's HTTP method. It is probably unwise to change an existing entry's atom:id value when issuing a PUT request.

5. Media Feeds

The entries within Media Feeds are feeds do not represent uniform types of content. For example, they might contain JPEG images, text documents, MPEG movies, and any other type of resource the server allows.

5.1 GET

Media Feeds return an Atom feed much like Text Feeds, but with a few additions. The entries also contain an atom:content element with a 'src' attribute pointing to the media resource. This URI can be used to edit the uploaded media resource, using PUT and DELETE. Such entries may contain pub:edit elements used to edit the entry metadata. As with other entries, derived resources can be located by inspecting an entry's atom:link elements.

An example Media Feed:

    <feed xmlns="http://www.w3.org/2005/Atom"   
          xmlns:pub="http://purl.org/atom/app#">
      <title>My Posts1</title>
      <author>
         <name>Foo</name>
      </author>
      <id>urn:uuid:ce61592c-14e2-4557-978e-dfbd444aefa6</id>
      <updated>2005-12-21T04:11:00-08:00</updated>
      <!-- 0 or more atom:entry elements follow -->
      <entry>
        <title type="text">Title25</title>
        <updated>2005-12-21T04:11:00-08:00</updated>
        <id>urn:uuid:941e12b4-6eeb-4753-959d-0cbc51875387</id>
        <link href="/permalink7.html" type="text/html" />
        <link href="/stuff/public/beach.jpg" type="image/jpg" 
              title="Low res public version" />
        <summary>This was awesome.</summary>
        <content src="http://example.org/asdf.jpg" />
      </entry>
      ...
    </feed>
The Atom Syndication Format requires that each such entry contain an atom:title and atom:summary element. This requirement can be challenging to meet without requiring users to enter tedious metadata, but servers should attempt to provide textual data about the resource in the interests of accessibility. The atom:title element will likely be provided by the client, as a way for users to associate their local resources with those they have uploaded to the server (see POST below).

5.2 POST

To add an entry to a Media Feed, clients POST the resource to the Media Feed's URI. Clients should provide a 'Title' request header to provide the server with a short string identifying the resource to users. Clients may include a 'Content-Description' header [RFC2045] providing a more complete description of the content. In addition, servers may inspect the POSTed entity for additional metadata to be exposed in an atom:entry element when listed in a Media Feed. For example, the server might inspect a JPEG file for EXIF headers containing creator data.

An example request:


An example response:



CategoryProposals