On Montag, 23. März 2009, David Raison wrote: > Hi folks, > > I've been reading your thread on "AnyDateTime" and stumbled upon this > quote from Markus: > > For most purposes, we would like > to implement an idea of a totally ordered, "physical" time, i.e. every two > input times should be comparable and correspond to real time points of the > world. This excludes inputs like "May 1" which would describe an infinite > number of recurring intervals that we are not prepared to handle. > > I was actually reading through the list because I'm quite interested in > a result format that could present recurring events on a weekly or > monthly basis. > > When you say, you're not prepared to handle that, what are the issues > involved? Are there no efforts being put into a recurring events feature? > I don't know whether I can find the time to work on it, but if you > could give me a few hints as to the problems, I might give it a try.
What I meant is that none of the time-specific features of SMW are able to deal with recurring dates. Take, for example, Timeline. The JavaScript is not able to dynamically load new events while scrolling on the timeline. Hence, all events must be passed to it during loading, which currently happens by embedding the data into HTML. It is unclear how to do that for recurring events, since one would have to pass all instances of these events to the script. The better solution, of course, would be to extend timeline to handle recurring events by itself. I have no idea how complex that would be. Another typical feature for dates is sorting. Again, it is not possible to sort a recurring date chronologically. Some things could be done for recurring dates of similar format, e.g. "Monday 11:00" is probably before "Wednesday 9:00", and "March 18" is before "May 12"; but it is not clear how "Monday 11:00" should compare to "March 18". So, sorting must be handled individually for all accepted formats, and suitable DB values must be found (currently, all sorting works by using either the alphabetic order of the stored values, or based on a numeric sort key that is assigned to single values). In any case, this way of sorting would not be compatible with complete datetimes that are supported today: partial dates would need to be a new datatype, not an extension of the existing Type:Date. Also note that each result of an inline query belongs to a single wiki page. It is not possible that a page occurs multiple times (e.g. if you wanted a table that looks like a one-month calendar with the same recurring event popping up each week). As in the case of timeline, a suitable repetition of recurring events would need to be implemented in the result printer. Finally, the Type:Date parser is based on the assumption that dates are complete (though possibly imprecise, e.g. if only a year is given). The parser thus would not work for inputs like "May 12" (it would assume this to mean "May in the year 12"). Again, new code is needed here. Summing up, partial dates would require a new datatype based on a new parser (that should still be essentially compatible with the Type:Date parser) and based on a new sorting scheme. Having a new type makes it hard to use partial dates and normal dates interchangeably (since they would have different properties), but it is problematic to mix partial and complete dates into one type (e.g. since inputs like "May 12" would then change their interpretation, and since sorting is rather unclear in this context). Result printers that should honour partial dates by showing them repeatedly would need modification. Yaron's proposal is an alternative: one could have some further predefined properties in the calendar extension that are honoured by the calendar printout format. Regards, Markus > > The background is that we're currently using semediawiki to handle our > events calendar (https://www.hackerspace.lu/wiki/Calendar and > https://www.hackerspace.lu/wiki/Main_Page) > Trouble is with recurring (weekly or monthly) classes or workshops. It'd > be very convenient to have such a feature. > > Thanks, > David > > --------------------------------------------------------------------------- >--- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Semediawiki-devel mailing list > Semediawiki-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- Markus Krötzsch Semantic MediaWiki http://semantic-mediawiki.org http://korrekt.org mar...@semantic-mediawiki.org
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
