Playback Sequence element

[Chris Kalafarski]

RFC Playback Sequence

There seems to exist a need to allow a feed to provide information to a client regarding the order in which content within that feed is expected to be consumed. Currently there is no reliable or agreed-upon way of indicating such an order. There are existing concepts for ordering in a feed (including pubDate, the order element within the iTunes namespace, and the order that items appear in a feed), but none specifically address the idea of the sequence in which the content producer most wants the content to be consumed by an end user.

There are a number of common patterns that apply to various feeds, and there is always the possibility that a feed’s content may best be consumed in an arbitrary order (as defined by the producer). Currently many client apps allow the user to, on a per-feed basis, choose either and ascending or descending order for displaying the items in the feed. Sometimes this preference impacts other operations, such as playback order or downloading files for offline consumption, but not always. And often times the client apps make some default determinations, when a user first subscribes to a feed, about which items from the back catalog (i.e. prior to the most recent episode) are marked as new or unheard, before the user being able to set that preference.

Consider, for example, a show that includes 20 episodes, all of which have already been produced and are available in the show’s feed (and no more episodes will be produced). This show is a narrative story, and generally only makes sense to listen to from the beginning, progressing through each episode in order (i.e. episode 1, episode 2, etc, ending with episode 20). If a user subscribes to this feed, in nearly all cases, regardless of which client they are using, they will likely be presented with episode 20 first, often times with episodes 1 through 19 being considered “heard” or “not new” by default. This is contrary to how the show should be consumed, and at best creates additional work for the user to clean up the data before listening to the show in the appropriate manner, at at worst creates such a confusing experience for the user that they are unable to listen to the show.

In order to start fixing this user experience problem, I believe a new, standardized element should be added to the syndiated.media core namespace that allows content producers to indicate in which order they would prefer their content is consumed. Developers of clients can likewise use the metadata defined by this element to more appropriately handle various behaviors within the client, such as the initial subscription, presentation of the items in the feed, which items should be downloaded and when, and handling new items as they become available.

As there are many different way in which a content producer may wish to order the playback of their content, and this is a new feature that will require adoption by both producers and developers, my suggestion is to start with adding this element, but limiting the scope of allowed values for the time being. More values and sequence patterns can be added in the future. The initial set of values should be defined very explicitly and unambiguously, so that future additions don’t conflict.

I further suggest that initially only a single behavior is included in the first version of the specification for this element, which would cover the case where the items in a feed should strictly be consumed oldest-to-newest, based solely on pubDate value. In situations where two items have equal pubDate values, the behavior would be undefined and the impetus would be on the content producer to ensure that episodes have distinct pubDate values when that is important.

I’m requesting comments on the follow specification:

A new element called playback-sequence is added to the syndicated.media core namespace
e.g. xyz:playback-sequence</xyz:playback-sequence>

This is a channel-level element, and can only be included once per channel. If multiple elements are present, that would be considered out-of-spec, and the behavior is undefined.

Two attributes are required on the element to define the expected playback sequence: key and value.
e.g. <xyz:playback-sequence key=“” value=“”></xyz:playback-sequence>

To indicate the aforementioned oldest-to-newest order based on pubDate, the entire element would look like:
<xyz:playback-sequence key=“pubDate” value=“ascending”></xyz:playback-sequence>

Future uses of this element would not necessarily use the key attribute to indicate an item-level element, and the value attribute would not necessarily indicate a binary ascending or descending value.

This RFC only covers a key of pubDate, and a value of ascending. A value of descending is not being proposed as part of this version of the specification.

[Cj Malone]

Although this is potentially more advanced, I think the updated Apple spec should be used. They'll have the most adoption and there's no need to try and compete

<type>episodic<type> being the current newest-episode-first and <type>serial<type> being oldest first.