Remove the list-template element, use the app:collection/@href IRI instead with atom:link[@rel="next"] linked feeds.




There is no real consensus on list-templates:

The core of APP needs [WWW]The Simplest Thing That Could Possibly Work: this STTCPW is a bare URI which, when dereferenced gives you an Atom Feed Document. Those feeds can be paged (chunked) and use links with a next relation to link from page to page.

Moreover, this Pace allows for a wider extensibility. Possible extensions are list-template (a perfect candidate, once consensus will be reached on its {parameters}) and [WWW]RFC3229 w/ feed on the collection IRI.

The next feed relation is described [WWW]here.


Remove section 7.3.5 (The 'app:list-template' Element) from draft-06.

Remove the following sentence from section 5.4

This IRI is constructed from information in the introspection document.

In section 5.4, replace the sentence

An Atom Feed Document is returned with one Atom Entry for each member resource
that matches the selection criteria in the IRI
An Atom Feed Document is returned with one Atom Entry for each member resource.

Delete the bullet list below section

Change the section 7.3.3 The 'app:collection' Element introduction to the following

The app:collection describes a collection. This specification defines one child
element: app:member-type.

In section 9, replace all but the first two paragraphs with:
For this reason, servers MAY return a partial listing containing the most recently
updated member resources. Those partial feed documents MUST have an atom:link with
a "next" relation and whose "href" value is the IRI of the next partial listing of
the collection (least recently updated member resources), except if there isn't such
a next partial listing.
In section 9, replace the first phrase with:
Collections, as identified in an Introspection Document, are resources that MUST
provide representations in the form of Atom Feed documents when dereferencing the
collection IRI.


Move from client-defined response length and random access to server-defined response length and sequential access.


This Pace uses the expression dereferencing the IRI. While incorrect, I think the note in section 2 is meant to allow it anyway.