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 <[email protected]> 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 un! less 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 [email protected]
