On Thu, Jun 10, 2010 at 15:43, James Snell <[email protected]> wrote:

>  <link rel="..." href="..."
>    notbefore="2010-06-10T12:00:00-08:00"
>    notafter="2010-06-10T01:00:00-08:00" />

'notbefore' and 'notafter' are pretty ideal.

> I would have no problem including these in the link extensions spec if
> the supporting use cases are sufficiently generic.
>
> However, it might make more sense to define these as extension
> elements to the link or entry... hard to say for sure without knowing
> more about the specific use case and how the your entries are being
> modeled.

Okay, bit of background: building a feed which contains information
about TV (or radio) programmes. there's some extra stuff in there
relating them to actual broadcasts (RFC4078 crid:// URIs), but
principally, it boils down to the usual atom:entry elements - title,
summary, id, published timestamp and links to resources.

What I'd like to include in this feed is a particular class of link
which refers to a resource (or set of resources of different types)
where the programme can be downloaded or streamed, generally for a
limited period - usually starting about half an hour after the on-air
broadcast concludes (at some point along the way I'll need to come up
with some link relations to indicate 'on-demand' vs. 'linear
broadcast', but that's a separate issue entirely).

The user agents can be quite a lot smarter if they can determine from
the feed whether a given programme is available for on-demand
viewing/listening at a given point in time  (not all will be, due to
rights constraints); if so, how long the user has access to the
resource, and if not, whether it will be for the future or if the
window has already passed.

I must confess I haven't thought deeply about wider applications of a
notbefore/notafter - obviously limited-time availability for resources
isn't particularly uncommon, but the intersection of those and the set
of resources you want to appear in a feed might well be a different
matter.

I'm happy enough to roll my own extension for this, but if it's
something generic enough to end up in link-extensions, I'd obviously
rather see that happen.

Cheers,

M.

Reply via email to