Link extensions-related: link availability/expiry?

[Mo McRoberts]

Hi list,

This isn't *directly* relevant to the link extensions draft, but does
lie along the same lines.

I'm looking for a pair of attributes which can be applied to an
atom:link which will indicate "not available until" and "not available
after" with regards to the linked resource. Does anybody know of
anything vaguely (be it official or de facto) standard?

I have a specific use-case in mind (indicating the availability of a
TV or radio programme for on-demand/'catch-up' playback), but I'm sure
there will likely be others, so if there's nothing out there
already...

Any pointers would be much appreciated!

M.

[James Snell]

There currently are no such extensions defined anywhere as far as I
know. A few years back I proposed a 'expires' extension element for
Atom entries that didn't get any traction. It would be a simple
matter, I think to define a pair of notbefore and notafter attributes
for the atom:link...

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

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.

- James

Post by Mo McRoberts
Hi list,
This isn't *directly* relevant to the link extensions draft, but does
lie along the same lines.
I'm looking for a pair of attributes which can be applied to an
atom:link which will indicate "not available until" and "not available
after" with regards to the linked resource. Does anybody know of
anything vaguely (be it official or de facto) standard?
I have a specific use-case in mind (indicating the availability of a
TV or radio programme for on-demand/'catch-up' playback), but I'm sure
there will likely be others, so if there's nothing out there
already...
Any pointers would be much appreciated!
M.

[Mo McRoberts]

 <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.

[James Snell]

This kind of time boxing certainly isn't unique... going to have to
give this one a bit of thought. Including these in the link extensions
draft would be trivial, just not sure if I'd be justified in doing so.

Post by Mo McRoberts

 <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.
[snip]

[Bob Wyman]

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

Post by Mo McRoberts

Post by James Snell
<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.

Post by James Snell
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.

[Bob Wyman]

An earlier version of the current xCal Draft included the specification of a
"link" element which was intended to bring into the calendar domain the link
element as defined by Atom. This element was removed from the current draft
as it is planned to specify it in a distinct draft. However, given that the
intention is to map what Atom provides, it would probably make sense for
folk to communicate with the authors about the proposed extensions to Atom's
link element. At the same time, it might make sense to request guidance from
the Calendar folk on how to handle the time-range attributes that are the
subject of this thread.

See the old (now removed) specification of LINK in Section 5 of the old xCal
draft (02):
http://tools.ietf.org/html/draft-daboo-et-al-icalendar-in-xml-02#section-5

<http://tools.ietf.org/html/draft-daboo-et-al-icalendar-in-xml-02#section-5>bob
wyman

Post by Bob Wyman
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

Post by Mo McRoberts

Post by James Snell
<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.

Post by James Snell
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.

[Mo McRoberts]

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...)

Ah, in this case, I know for a fact that at a given point in time, there will only be one window for a given linked resource (although the 'window' may have either of no start or end time restriction, depending). That doesn't mean the <entry> won't be revised in a future copy of the feed, but that's perfectly fine. Note that it's not referring to times of the broadcasts themselves — there are whole reams of specifications dealing with those. Fortunately, for these purposes, I don't much have to care :)

However, comments noted — it may well be that something simple and generic isn't useful enough in the general case to warrant being part of, say, the link extensions draft. I can see why there has been opposition to such things in the past, certainly — thanks Bob.

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.

I'll take a look a the xCal stuff (and the 02 draft too). I don't mind pulling in stuff (I’m already dragging in Programmes Ontology and TV-Anytime elements for other aspects of the feed) — it’s just that I want to avoid defining it myself (possibly quite badly!) if somebody else has already done it, or is in the process of doing so.

M.

[James Snell]

Bob definitely makes an excellent point. To be honest, I was thinking
along the same lines also but wanted to take some more time to think
things thru.

Post by Mo McRoberts

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...)

Ah, in this case, I know for a fact that at a given point in time, there will only be one window for a given linked resource (although the 'window' may have either of no start or end time restriction, depending). That doesn't mean the <entry> won't be revised in a future copy of the feed, but that's perfectly fine. Note that it's not referring to times of the broadcasts themselves — there are whole reams of specifications dealing with those. Fortunately, for these purposes, I don't much have to care :)
However, comments noted — it may well be that something simple and generic isn't useful enough in the general case to warrant being part of, say, the link extensions draft. I can see why there has been opposition to such things in the past, certainly — thanks Bob.

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.

I'll take a look a the xCal stuff (and the 02 draft too). I don't mind pulling in stuff (I’m already dragging in Programmes Ontology and TV-Anytime elements for other aspects of the feed) — it’s just that I want to avoid defining it myself (possibly quite badly!) if somebody else has already done it, or is in the process of doing so.
M.

[Sam Johnston]

Post by James Snell
Bob definitely makes an excellent point. To be honest, I was thinking
along the same lines also but wanted to take some more time to think
things thru.

Surely by the time you get to putting entries in a feed you already know the
window within which they are valid? Parsers already understand rfc3339 so
I'd lean in the direction of notbefore/notafter with rfc3339 times rather
than something nontrivial (however flexible). One can always expose more
complex recipes for more complex applications using another attribute.

Sam