- From: Greg FitzPatrick <greg@shortlist.se>
- Date: Sun, 09 May 2004 14:21:48 +0200
- To: Graham Klyne <gk@ninebynine.org>
- Cc: Libby Miller <Libby.Miller@bristol.ac.uk>, rdfweb-dev@vapours.rdfweb.org, par@lannero.com, www-rdf-calendar@w3.org
Graham Klyne wrote: I'd completely overlooked SKICal work... Dear Graham, Libby and friends, Sorry, we are working on getting www.skical.org back up. I afraid we missed a renewal:-( Here is some more information that might also have been forgotten, perhaps expeditiously so – who knows? SkiCal was an attempt to create a schema extending RFC2445 to cover all possible public “resources”. Resources in this case meaning just about anything a human or organization could interact with! (timidity was not our hallmark). In order to interact you might want to know what was offered – by who, when, where etc... And you might want to know just what sort of technicalities or requirements were involved in such an interaction. And you might just be able to sync this information with your own calendar. A souped up yellow pages, as someone called it. We were counting quite heavily on the centralist nature of Sweden, (SKI is an acronym for “/Svenska kalendarium initiativet/”) to establish standard usage of our schema. That is, we thought we could convince government to stipulate the use of SkiCal for the entire flora of its resources, and the resources it subsidized (which are considerable), in order to save money and better the lot of our citizenry - or at least get them to the cinema on time. Since commercial operations, such as CitySearch, then as now preferred to regard their listings of some one else's public events as their own private property, we figured that the only way to get them to go along, was through government fiat. Our primary target for SkiCal implementation was publicly funded national and local tourist boards. With enough SkiCal out there, others would be forced to follow suit, or so we reasoned. Our first IETF draft entailed moderate extensions to RFC2445. We were inspired by the fact that browsers at that time (1999) could rather effortlessly download vCard and vCal/iCal objects and insert them into savvy scheduling applications. As we continued to update our drafts, spurred on by IETF's 6 month expiry limits, we merrily added more and more “features”, despite the fact that adoption of our first schema was moving on very slowly (albeit not insignificantly). The first draft from 1999 can be found here: http://www.watersprings.org/pub/id/draft-many-ical-ski-01.txt It was promoted by the Swedish National tourist board and the tourist councils of the larger cities here. I wrote a paper for XML 2001 in Orlando... http://www.idealliance.org/papers/xml2001/papers/html/05-04-06.html#d28e45745 ...an absurdly ambitious effort to explicate the state-of-the-art of the date-time aspects of “the souped up yellow pages”. As a whole it is most likely unreadable, but some of the problems with iCal/ISO8601/XML Schemas I covered therein are, as far as I know, still relevant today: Ambiguities caused by start/end inclusive – exclusive date-time formats. Inconsistencies in calendar-explicit – period-explicit durations Representation problems with “midnight crossings” (when Cinderella turns into a pumpkin) The only comment I ever heard on the Orlando paper was from my volleyball buddy DanC, via DanBri, who said I was refining the art of micro-parsing – I don't think it was meant as a compliment:-). I also wrote a paper for WWW2002 in Honolulu on directories, where SkiCal was exemplified. In this paper I gave some of the arguments against universal (unified schema) directories. http://www2002.org/globaltrack.html The “current” SkiCal draft #6 was written in 2002. It has a self standing “Opening Times” schema written in XML. Since SkiCal #06 is itself in mime-directory format, I included the opening times declaration as encapsulated XML. http://www.watersprings.org/pub/id/draft-many-ical-ski-06.txt That's it. Nice weather we're having, Greg
Received on Sunday, 9 May 2004 08:24:19 UTC