Subject: [Forward] vTODO due/duration conflict

From: JP Rosevear <[email-masked]>
Date: 26 Feb 2001 18:54:31 -0500

Resend of this.

-JP

-- 
--
=======================================================================
JP Rosevear                             [email-masked]
Ximian Inc.                             http://www.ximian.com

Subject: vTODO due/duration conflict
From: JP Rosevear <[email-masked]>
To: [email-masked]
Date: 13 Feb 2001 19:23:37 -0500

I've noticed that for a to do component that due and duration are
mutually exclusive.  I take it that duration is relative to the dtstart
property, but the dtstart parameter is optional so you could get a
floating duration that is meaningless (ie always due some amount of time
hence) in the intended context it would seem.

Something like this would be useful however for time estimates of a to
do item.

Thoughts?

-JP

-- 
--
=======================================================================
JP Rosevear                             [email-masked]
Ximian Inc.                             http://www.ximian.com

---

From: [email-masked]
Date: Tue, 27 Feb 2001 16:48:40 -0500

JP noted:
>          I take it that duration is relative to the dtstart
>property

If you check RFC 2445, Section 4.8.2.5 it clearly defines the use of 
DURATION in place of DUE:

           In a "VTODO" calendar component the property may be used
   to specify a duration for the to-do, instead of an explicit due
   date/time. 

so when the ToDo has a non-hard ending.  For example: "Press 50,000 CDs to 
ship to customers" takes 2.5 days from the start of the effort.  So if the 
DTSTART gets pushed out due to bug fixes, the 'end' date/time for the Task 
gets pushed out too.  However my "Pay your 2001 taxes" (US reference here) 
MUST be done by 04162001T045959Z (Im in EST) or I will be penalized so a 
DUE is what should be used.  There are clearly 2 different needs for 'end 
date/times'.  Im not sure how mixing & matching would work nicely (ie: 
cleanly combine my 2 examples into 1 coherent case) so lets not try going 
there.

>but the dtstart parameter is optional so you could get a
>floating duration that is meaningless

Yep, its an oversight in our ABNF (since it superceedes the prose) but I 
suspect that its more like "I dont know how to do that in the ABNF so it 
stays unchanged until someone complain" on the editors part.  The ABNF in 
Section 4.6.2 should be amended (and the prose too) to be more accurate 
but Im not ABNF god who can make dtstart required IFF duration is used but 
optional otherwise.  I tried for 10 min and could not make it clean, 
perhaps somone can get Harald to fix it up for us... 

 The more I gaze at it the more I think the approach is wrong to this 
problem.  Technically the ABNF _text_ is the only thing precluding a DUE 
and DURATION, its _NOT_ the ABNF itself!!  See:

     todoprop   = *(
[Snip]
                ; either 'due' or 'duration' may appear in
                ; a 'todoprop', but 'due' and 'duration'
                ; MUST NOT occur in the same 'todoprop'

                due / duration /

So unless someone wants to redo the ABNF to make either/or optional but 
mutually exclusive (and include DTSTART in there too), I would suggest 
amending the text in the ABNF to something like:

                ; either 'due' or 'duration' may appear in
                ; a 'todoprop', but 'due' and 'duration'
                ; MUST NOT occur in the same 'todoprop'
                ; If a duration appears then a dtstart MUST
                ; also occur.

Bruce
Mr. KISS
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Tue, 27 Feb 2001 16:55:33 -0500

Gilles suggested:
>It seems to me very useful to have a duration for a to do component, for
>time estimates in the context of project management for instance. I do 
not
>seen any reason why this would conflict with a due date?

The duration concept you are referring to is not "How long _should_ it take for this ToDo" but "How long _did_ it take to complete this ToDo".   The difference is subtle.  If you or 
someone wants to coin a new property to indicate this then propose away 
but the WG made a conscious decision way back NOT to do "project 
management" features in iCalendar. 

As such DURATION is used for the former case, not the latter.  I think 
that we decided that to achieve the latter case you would use COMPLETED 
instead so that you could track from DTSTART, how long it should have and 
how long it actually did take to complete.  So, I retract my suggestion on 
penning a new property; "Its in there".  I think the only fix needed is to 
require a DTSTART if DURATION is to be used.  Simple and sufficient 
(unless Im missing something).

Bruce

---

From: [email-masked]
Date: Tue, 27 Feb 2001 16:59:17 -0500

John suggested:
>That sounds useful; but it would probably be safer to define a separate
>property.

What would a new property achieve??  We already have COMPLETED so you can 
tell if the ToDo was longer, shorter or matches the DURATION value given a 
DTSTART.  The only problem seems to be that we didnt codify that DTSTART 
MUST occur if DURATION occurs in a VTODO and thats a simple 1-2 line 
update to the ABNF text.  Unless Im missing something in Gilles and JPs 
postings...

Bruce

---

From: [email-masked]
Date: Wed, 28 Feb 2001 02:03:52 -0600

> What would a new property achieve??  We already have COMPLETED so you can
tell if the ToDo was longer, shorter or matches the DURATION value given a >
DTSTART.  The only problem seems to be that we didnt codify that DTSTART
MUST occur if DURATION occurs in a VTODO and thats a simple 1-2 line update
to the ABNF text.  Unless Im missing something in Gilles and JPs postings...

Bruce: We didn't codify the DTSTART on the DURATION because we were also
thinking of the scenario where you want to specify a set of VTODOs (with the
RELATED-TO property) such that the 2nd, 3rd, ..., Nth action items as
relative to the first one. That way you could change the 1st one and the
others would automagically get updated with the proper start date.
 
FYI.
 
-- Frank

---

From: [email-masked]
Date: Wed, 28 Feb 2001 10:32:25 -0500

Frank replied:
>We didn't codify the DTSTART on the DURATION because we were also 
thinking 
>of the scenario where you want to specify a set of VTODOs (with the 

  Thanks for the info as to why it was written the way it was.  Hmm, I 
must have been out when that train of thought passed thru the station. 
This is a slightly different use of the original intent of RELATED-TO.  I 
do not recall us using RELATED-TO for inhereting of start/end times, it 
was intended just "To specify the type of hierarchical relationship associated with the 
calendar component specified by the property." 

  This does raise the question then of what is it relative to, the 
DTEND/DUE/effective DUE of the RELATED-TO entity or the DTSTART.  It 
sounds like you are implying the DTSTART but I dont like assumptions in 
interop specs (sic: multiparts!).  I could also see the argument for 
making it 'end realtive' (ie: Once Task A is done, Task B is due 2 days 
later).  Also, given there can be multiple RELATED-TOs Im curious which 
one(s) should be used to inherit the info: Parent(s), Children, Siblings, 
a mix? While I do like the intent, I see a slipery slope coming up... 
Could you please clarify this before we make further assumptions??

  So, now that we are on the same page (mostly), the next topic is to 
codify this info in the RFC update to address JPs quandry. 

  So far the clamor of stampeding feet of folks who want to redo the ABNF 
is deafening silence so I would propose we address this in ABNF comments 
and some clarifying prose.  To make Erics job easier Ill propose the 
following:

1: Update the ABNF text for the VTODO component to include the following 
below the current text about DUE vs DURATION:

for the more typical case of 'standalone' VTODOs in our usage model.

2: Add prose to Sections 4.8.2.3 Date/Time Due and 4.8.2.5 Duration that 
clearly indicates Franks described intent or if the WG decides to preclude 
it, rules it out for now.  Given the number and complexity of questions 
that arise about multiple RELATED-TOs and start vs end inheritance, Im of 
the KISS mind to pass on this concept for now.  We have bigger eFish to 
fry (ie: Recurrence rule updates)...

Others??

Bruce

---

From: [email-masked] (Gilles Fortin)
Date: Wed, 28 Feb 2001 17:31:03 -0500

>for the more typical case of 'standalone' VTODOs in our usage model.

I totally disagree with this. DURATION should be independant of DTSTART and
of DUE.
You may want to define a VTODO "Write income tax statement" that you
estimate will take you 4 hours to do, and which you have to complete by a
legal dead line. If you calendaring application is able to sum up the
durations of your to dos, you will have idea of your future workload. Once
you has done the work, you can then record the actual time it took for a
better estimate next year...

I simply do not understand the rationale behind the restriction in RFC 2445:
                ;either 'due' or 'duration' may appear in
                ; a 'todoprop', but 'due' and 'duration'
                ; MUST NOT occur in the same 'todoprop'

Gilles Fortin, Founder & President
__________________________________
Teamsoft Inc.
50 Queen, #304
Montreal, Canada H3C 2N5
+514-875-2231x106    fax:+514-875-2401
Internet: [email-masked]    Web: http://teamsoft.com