-1 for a bunch of reasons.
Thomas Broyer wrote:
>
> http://www.intertwingly.net/wiki/pie/PaceConfigurableCollectionOrdering
>
> == Abstract ==
>
> Adds flexibility to PaceOrderCollectionsByAppModified by allowing
> servers to expose the collection ordering (based on entry creation
> date/time, atom:updated or app:modified).
> Actually, this is not about configuration, but the server's behavior
> will likely be configurable, so it's rather about exposing the
> server's configuration.
>
> == Status ==
>
> Open (ThomasBroyer)
>
> == Rationale ==
>
> In "online mode", a client will always GET the entry before editing
> it, so the collection feed is only helpful in notifying new entries.
> Other orderings (by atom:updated, which is mainly designed for
> subscriptino/aggregation, or by app:modified, which is designed for
> sync'ing before going offline) would be here unnecessarily bandwidth
> consuming.
>
> When synchronizing for "offline mode", such an ordering (by a pseudo
> "app:created") could be sufficient and the client would issue
> conditional GETs on every known entry to ensure it has the latest
> version, but this algorithm involves many round-trips and is very
> bandwidth consuming, and consumes more and more bandwidth whilst the
> number of entries grows, even if none of them has changed. Ordering by
> atom:updated does not solve the problem. Ordering by app:modified here
> is the best approach.
>
> We need a configurable approach, where the server can be configured
> (or at least expose their implementation/configuration) depending on
> their use (optimized for online editing, optimized for offline
> editing, optimized for subscription --implies almost optimized for
> online editing--).
>
> == Proposal ==
>
> Replace the second paragraph of section 9 in draft-atom-protocol-09 with:
> {{{
> The ordering of entries in the feed depends on the value of the
> "app:details-level" element (see section 10.3).
> }}}
>
> Add the following two new subsections in section 10:
> {{{
> 10.3 The "app:details-level" element
>
> appDetailsLevel = element app:details-level {
> atomCommonAttributes,
> "creation" | "update" | "minor-change"
> }
>
> The "app:details-level" element MAY appear as a child of an
> "atom:feed" which represents a Collection. The "app:details-level"
> element, if it does appear in a feed, MUST only appear at most one
> time. The "app:details-level" element is considered foreign markup
> as defined in Section 6 of [RFC4287].
>
> The "app:details-level" element's content MUST be either "creation",
> "update" or "minor-change". If the "app:details-level" is not
> provided, both clients and servers MUST behave as if it were present
> with a value of "update".
>
> The value "creation" means that entries in the Atom Feed are ordered
> by their "app:created" value (see section 10.4). Every entry in the
> feed MUST then have an "app:created" or "atom:published" element.
>
> The value "update" signifies that entries are ordered by their
> "atom:updated" value.
>
> The value "minor-change" indicates that entries are ordered by their
> "app:modified" value (see section 10.5).
>
> Both clients and servers MUST ignore foreign elements present in the
> "app:details-level" element.
>
> 10.4 The "app:created" element
>
> appCreated = element app:created { atomDateConstruct }
>
> The "app:created" element MAY appear as a child of an "atom:entry"
> which is being created or updated via the Atom Publishing Protocol.
> The "app:created" element, if it does appear in an entry, MUST only
> appear at most one time. The "app:created" element is considered
> foreign markup as defined in Section 6 of [RFC4287].
>
> The "app:created" element is a Date construct indicating the instant
> in time when the entry was created.
>
> If the "app:created" element is not provided and the entry contains
> an "atom:published" child element, clients MUST behave as if the
> "app:created" element were present with the same value as the
> "atom:published" element.
>
> If the "app:created" element is present in an Atom Entry sent to a
> server in the body of a POST or PUT request, the server MUST ignore
> it and its value.
>
> 10.5 the "app:modified" element
>
> appModified = element app:modified { atomDateConstruct }
>
> The "app:modified" element MAY appear as a child of an "atom:entry"
> which is being created or updated via the Atom Publishing Protocol.
> The "app:modified" element, if it does appear in an entry, MUST only
> appear at most one time. The "app:modified" element is considered
> foreign markup as defined in Section 6 of [RFC4287].
>
> The "app:modified" element is a Date construct indicating the instant
> in time when the entry was last modified. The "app:modified" element
> is very similar to the Last-Modified HTTP header, thus, when included
> in an Atom Entry Document, its value SHOULD be the same as the one of
> the Last-Modified HTTP header applying to the entity.
>
> If the "app:modified" element is not present, clients MUST behave as
> if it were present with the same value as the "atom:updated" element.
>
> If the "app:modified" element is present in an Atom Entry sent to a
> server in the body of a POST or PUT request, the server MUST ignore
> it and its value.
> }}}
>
> In section 7.2.3 (the "app:collection" element), replace the second
> sentence with:
> {{{
> Two child elements are defined here for app:collection: app:accept and
> app:details-level.
> }}}
>
> Add the following new subsection to section 7.2:
> {{{
> 7.2.5 The "app:details-level" element
>
> The app:collection element MAY contain one "app:details-level" element.
> The "app:details-level" element is defined in section 10.3.
>
> When used as a child of app:collection, its value is a hint for
> clients and SHOULD have the same value as the "app:details-element"
> present in the Atom Feed referenced by the app:collection's "href"
> attribute. Note that the "app:details-level" element within an
> app:collection does not override the actual media type returned within
> the Collection's Atom Feed.
> }}}
>
> == Impacts ==
>
> Example usage: clients could warn users that the server's
> configuration is not optimized for the use they want (online or
> offline mode), so they could fix the server's configuration (if they
> can, of course).
>
> == Notes ==
>
> This Pace uses the "app" namespace rather than the "pub" one, as if
> PaceOneAppNamespaceOnly had been accepted, but it does '''not'''
> depend on it.
>
