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 unl! ess 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.
