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

Attachment: 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

Reply via email to