In this document, I wish to explore how feeds may be implemented in a hypertext artifact such as the one I am designing. In order to define feeds for this site, I must first take a look at what a feed is:
There are three major ways a feed can be serialized. Each of these has semantics that are slightly different, but overlap mostly with the other two. It therefore makes sense to represent feeds internally as the union of these three formats, and then provide functions to access each representation as a facet of the internal structure.
Clients can request specific feed variants by way of the Accept HTTP header:
Along with other resources, the system could allow the Accept header to be overridden by the URI query string.
With an abstract internal structure that depicts events, it becomes extremely attractive to address feeds as derivations of other resources. This way, the system could expose a feed for any resource or set of resources within it. The feed could be accessed, for example, by appending a path parameter to its URI, like http://example.org/some-page;feed.
This strategy depends, however, on whether or not a feed could always be defined as being about another resource.
To satisfy those that have asked, I have placed a provisional feed at a temporary location. I will update this feed when I add new documents to the site. Once I have chosen a final location for it, I will permanently redirect all requests, though the feed will be accessible by its UUID in perpetuity.