Subject: Re: SKI Presentation in Oslo

From: [email-masked]
Date: Tue, 17 Aug 1999 18:04:08 GMT

But let's be clear. While we have "listened" to the SKICAL postings to 
this list and their presentation at the Oslo IETF WG meeting, we are still 
waiting for a succinct set of (hopefully written) requirements beyond 
those already specified by this WG for the current iCalendar family of 
RFCs.
-- Frank

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Wed, 18 Aug 1999 00:12:55 +0200

Frank Dawson wrote 1999017:

But let's be clear. While we have "listened" to the SKICAL postings to this
list and their presentation at the Oslo IETF WG meeting, we are still
waiting for a succinct set of                (hopefully written)
requirements beyond those already specified by this WG for the current
iCalendar family of RFCs.

 ----------------------------------------------------------

My sincere apologies to the working group.  I am afraid that we take
ridiculously long vacations in Sweden.  I was very sad to see all the
unanswered mails addressed to me by this group.

Despite the vacations, we have made progress on several fronts.

Here is our current BOK  http://www.skical.org/ftp/Ski85.txt  where written
requirements from the SKi WG can be found.

Here is my argument for Scheduled times which never  made the list:

Steve Mansour wrote:

>The requirements/need for "probable/probably" times are not entirely clear.
I
>assume you're breaking these out into separate requirements because setting
the
>event status to TENTATIVE is not sufficient. Can you provide an example of
each
>and make the distinction clear? It would really help to understand.

I will try to be more precise.  You are right. TENTATIVE does not cut it.
Ramadan is a good example.  It is not any more tentative than Christmas, but
the dates when it will occur are, since the mullahs have to make a decree.

case:
James is definitely having a birthday party and it will definitely be on the
3rd of June!

STATUS:CONFIRMED
Time property =CONFIRMED to June 3rd

case:

James is definitely going to have a birthday party. We have planed it for
some time between the 2nd and the 4th of June.

STATUS:CONFIRMED
Time property=Scheduled  between the dates of June 2nd and June 4th

case:
We are planning a party for James, it may or may not happen, but if it does,
it must happen on the 3rd of June - his birthday!

STATUS:TENATIVE
Time property = Confirmed to June 3rd

case:
We know how much this means to James, still we must think of the cost. If we
do have a party though, it could be at any time between the 2nd and the 4th.

STATUS:TENATIVE
time property = Scheduled  between the dates of June 2nd and June 4th

Now I am not saying this is necessarily the best way to solve the problem,
it could also be done with the help of a qualifier inside the Event property
or a qualifier for the STATUS property. But we had already made a decision
that OPENINGTIMES should be a new component and it seemed natural to deal
with SCHEDULEDTIMES in the same way.

Our development partners in Sports and Entertainment have a real need for
this.  Confirmed events at approximate dates and times is a reality.
Try to work out a model for the Winter Olympics without this function:-)

As for the name of the property, I got it from Frank. When I approached this
group about the need for a property called "opening times",

Frank responded with the following:

>I think the "opening times" that KilPatrick (he got the capital P right -
my note) >was suggesting is
>meta-information about what is "schedulable" on the given calendar.
>Certainly, the current iCalendar specification would allow you to introduce
>"non-schedulable hours" as opaque events. We would have the problem with
>systems that allow conflicting appointments/meetings to be scheduled. What
>we really need is the "schedulable hours" property we have discussed in the
>CAP discussions.

Schedulable hours - Schedulable days - Scheduled times.

Presently we are discussing how scheduled times are going to show up for an
event seeker.
If someone scheduled an event to happen at any time during 1999 (like a
crash in Internet related stocks) we would not want that to show up on every
day of a person's event harvester.

------------------------------------

Here is some more correspondence which did not make the list:

>Steve wrote:

>By the way, I like the idea of some of the properties in your doc. In
>particular:

     VENUE
     ORIENTATION
     DIRECTIONS
     QUALIFICATION
     PRICE
     TICKETS_AT
     ADVERTS

Greg's answer

Thank you.

>Some seem strange. For example, AVAILABLE, seems like a highly volatile
>property... It's not clear what you had in mind for storage of this
property.

I admit AVAILABE does seems very volatile when taken out of the WHOW
context.
The Swedish tourist board has pushed this as a generic term for a limited
resource which can be represented in numbered quantities. It differs from
RESOURCE in the respect that it could facilitate an online countdown of
things like Seats, Beds, chairs and rooms.

So that a RESOURCE could be

20 beds

of which

5 where momentarily AVAILABLE

This is also a major element in the Cinema and other theater's online
ticketing ambitions.

Here is what the movie people here think are the most important tags for a
very thin client (like WAP) situation.

The Name of the Movie
The location of the theatre
The viewing times
The age restriction
The amount of seats available (on-line)

Of course we must uphold a balance as to how far we should stretch
ourselves.  Maybe we should stay clear of trying to fit things like "on-line
count downs" in to the Calsch work.  You tell us.

I read you had parking lots in the states which had the amount of slots
available on line so that you could check them out before driving there.

RESOURCE: 250 slots
AVAILABLE: 3

Greg FitzPatrick

------------------------------------------

Here is Niklas Hjelms original argument as to Opening Times problems:

Problems about the representation of Opening Times in iCal: Periods can be
multiple but only in the same scale and not nested.
Periods are not allowed in exceptions.

Suggestion: Allow PERIOD in RRULE and EXRULE. But better still - define
combined rules, i.e. (I know those c++ comments are not allowed, but it
would have been nice).

	BEGIN:UNION //new keyword

	DTSTART:19870405T020000z
	RDATE;VALUE=PERIOD:19000401T000000Z/19000930T240000Z
	RRULE:FREQ=YEARLY

	//9.00-17.00 mo-fr
	DTSTART:19000401T090000z
	RDATE;VALUE=PERIOD:19000101T090000Z/PT8M
	RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;UNTIL=19000930T170000z

	//12.00-15.00 sa-su
	DTSTART:19000401T090000z
	RDATE;VALUE=PERIOD:19000101T120000Z/PT3M
	RRULE:FREQ=DAILY;BYDAY=SA,SU;UNTIL=19000930T170000z

	END:UNION

About Holidays:

Easter, and many non-western holidays, depend on the phase of the moon.
Either you could  get the moon phase from the calendar application by
defining
the rule part "BYMOON" 0-100 (where 100 is full)like this:

	SUMMARY;Easter
	RRULE;FREQ=YEARLY;BYMONTH=3,BYMONTHDAY=21,BYDAY=SU,BYMOON=100

Otherwise we need to reference some custom definition. I don't know how to
do
that without defining a new programming language. The following example is
 meant merely as food for thought:-)

	BEGIN:REF
	NAME:moon
	//Full moon
	DTSTART:190000T000000z //enter some known full moon...
	RRULE;FREQ=SECONDLY;INTERVAL=2551443
	END:REF

	SUMMARY;Easter
	RRULE;FREQ=YEARLY;BYMONTH=3,BYMONTHDAY=21,BYDAY=SU,BYREF=moon

--Niklas