Re: Link extensions-related: link availability/expiry?

[Bob Wyman <bob@xxxxxxxx>]

Simple solutions are wonderful! Unless they are simple solutions to complex problems. The harsh reality is that for a solution to be effective, its complexity must *at least* match the complexity of the problem solved. In this case, the specification of time ranges is a complex problem and any "simple" solution to it will result either in disuse (since the solution is inadequate) of increased complexity in the future as people extend the basic capability to handle the unaddressed complexity of the problem domain. Personally, in the over 30 years I've spent in this business, I've seen uncounted attempts to address the "time range" problem simply. Each effort begins with someone proposing the "simple" solution of "start" and "end" times. But, then fairly soon thereafter, someone appears with the requirement for discontinuous time ranges... i.e. The event occurs from 8:00pm to 9:00pm Eastern Standard Time on Tuesday evenings during the months of September through December unless it is the first Tuesday in November during a year that is evenly divisible by 2, in which case, the broadcast will occur one hour earlier. (i.e. time shifting to compensate for poll closing during US elections...)

Rather than defining something new, I would strongly encourage you to take a long hard look at the xCal Draft and attempt to ensure that whatever is done here, if anything, is compatible with that specification. The ideal would be to define these attributes as incorporations of the xCal methods rather than to define something entirely new.

See: http://tools.ietf.org/html/draft-daboo-et-al-icalendar-in-xml-04

The "time specification" or calendar problem is terribly vexing and difficult. Please, don't try to reinvent the wheel...

bob wyman

On Thu, Jun 10, 2010 at 11:01 AM, Mo McRoberts <mo@xxxxxxxxxx> wrote:

On Thu, Jun 10, 2010 at 15:43, James Snell <jasnell@xxxxxxxxx> 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.