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

[James Snell <jasnell@xxxxxxxxx>]

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.

On Thu, Jun 10, 2010 at 10:03 AM, Mo McRoberts <mo@xxxxxxxxxx> wrote:
>
> On 10-Jun-2010, at 17:04, Bob Wyman wrote:
>
>> 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
  http://www.snellspace.com
  jasnell@xxxxxxxxx