Subject: FW: Scheduling times aka Fuzzy Logic

From: "greg fitzpatrick" <[email-masked]>
Date: Fri, 27 Aug 1999 21:29:04 +0100

I believe this thread does better under the name Scheduling times, a topic
many are interested in - rather than Fuzzy Logic,  a subject of importance -
but not of urgency!
Frank Dawson has made some good  suggestions for solving the "time/date
tentative" scheduling needs which SKiCAL has been harping on for some time
now.   Since, when I read Frank's proposal, I was operating in my
oppositionist modus, I interpreted Frank's new property parameters as
examples of what we shouldn't do, - so - pie on my face,  sorry Frank,  I
would like to discuss these parameters now if I may?
Parameter:  SCHBUF
A "meeting buffer" for travel arrival and departure of participants - Frank.
 
This caused us a good laugh, since in Scandinavia, University lecturers of
the old school, have traditionally exercised the custom known as the
"Academic Quarter",  which is a sort of droit de proffeseur  to come 15
minutes late to one's class.   SCHBUF could be seen as a method for the
metadata semantification  of this practice.  But actually that would not
work in this case, since Frank assumes that a SCHBUF would abut to the
OUTSIDES and not the INSIDES of  DTSTART and DTEND.
    SCHBUF------DTSTART------------------------DTEND------SCHBUF
Not that I want to help the teachers come late, but there might be reasons
why this parameter could have a - or + value indicating whether it was to be
parsed as outside or inside DTSTART and DTEND.   
The biggest problem with this parameter  I can see, is the inability to
explain to the parsing CUA why it is there, sic what is the meaning of the
value expressed.   On the other hand, SCHBUF might be useful for keeping
open ended fragments out of conference schedules where adjacent meetings
will usually not abut front to back  on account of the need for washroom and
smoking  breaks in between meetings.     
SKiCAL has never discussed the need for something like this SCHBUF before
and right now we are neutral on its value.
Parameter SCHRANGE
A "schedule range" for providing participants a priori knowledge of
permissible alternative meeting times.  - Frank
Now this is our kettle of fish.  It suits us to a T.  Here is a mechanism
for declaring a "window of possibilities" a  range of potential dates for a 
meeting or event.
I have just a few questions.
RFC 2445 says that the DTSART property is required in a VEVENT component and
must be one of the forms defined for the DATE-VALUE type.   This means that
an event publisher would have to declare some sort of DATE-TIME in order to
state the SCHRANGE.  
The DATE-TIME following a SCHRANGE declaration might be significant as the
apex of possible DATE-TIMES, the most likely or most attractive time for a
meeting,  and the SCHRANGE values would indicate the limits of the
possibility window; 
b                            x DTSTART = June 6th
e                         x   x
s                       x        x
t                    x              x
                 x                       x
             x                               x
SCHRANGE START                            SCHRANGE END
June 3rd    June 5th    June 7th    June 9th    June 11th
or it might have no significance at all, since there might not be a date
within the scheduling range which is in any way more suitable for a meeting
than any other day and we would not like it to be considered so.
Any solutions to this?  Any way of indicating a non-significant DTSTART
within a SCHRANGE?
Anyway of avoiding having to declare a DTSTART altogether ?
 
Frank's example also declares that the STATUS property is to be set to
TENTATIVE when using SCHRANGE.  
Can't we make it easier on the CUA parser, by defining a STATUS, which
indicates DATE-TIME tentativeness rather than EVENT tentativeness?  Event
tentativeness is  uncertainty  over whether the meeting will be held or not?
 DATE-TIME tentativeness is  uncertainty  over exactly when  the meeting
will be held?
Greg

---

From: [email-masked]
Date: Tue, 31 Aug 1999 21:35:46 GMT

>OUTSIDES and not the INSIDES of  DTSTART and DTEND.

Hadn't really given deep thought to it being an outter versus an inner 
band. My basic line of reasoning was that an event has defined start and 
end. The buffer around the event would take into account traditional 
delays of travel to/from an event. 
Certainly, we could define it using parameters similar to what we have in 
VALARM for trigger where we would allow pre- or post- buffer to a DTSTART 
or DTEND. That way, you can handle either the pre-buffer case for DTSTART 
or the post-buffer case.
Does this make sense?
-- Frank

---

From: [email-masked]
Date: Tue, 31 Aug 1999 21:38:12 GMT

Greg Fitzpatrick wrote:
>On the other hand, SCHBUF might be useful for keeping

Actually, breaks can be scheduled as separate events too, rather than 
addressed with schedule buffering. Because you want them to setup such 
that there are no other events scheduled during these periods.
-- Frank

---

From: [email-masked]
Date: Tue, 31 Aug 1999 21:44:11 GMT

>possibility window; 

<snip/>

>Any solutions to this?  Any way of indicating a non-significant DTSTART
It is important to have a common data model for events. They have a start 
and an end. I would suggest that the DTSTART be the first possible start. 
The end the corresponding first possible end. Then use the SCHED-RANGE 
property to specify the flexibility for the event. If you have a schedule 
range, then you certainly could use this logic to always specify a DTSTART 
and DTEND. Right?

>Anyway of avoiding having to declare a DTSTART altogether ?
Don't see how. However, if you have range of dates, per above, this ought 
to be no problem to specify.
-- Frank

---

From: [email-masked]
Date: Tue, 31 Aug 1999 21:47:42 GMT

> DATE-TIME tentativeness is  uncertainty  over exactly when  the meeting
Certainly. My sloppy examples. Sorry. By all means, we probably want to 
think about defining an extended enumeration value for this property. You 
may want to discuss what the real semantics are. Somewhere didn't someone 
refer to this as "UNDECIDEDNESS" for events? Maybe a STATUS value of 
"DATE-TIME UNDECIDED" makes sense?
-- Frank