Subject: Re: CAP (Hierarchial calendars) - latest intem draft

From: [email-masked]
Date: Thu, 10 Jan 2002 12:07:13 -0500

Doug replied:
>>   I think that the CHILDREN property does have a predefined meaning
>> in CAP. If it's decided that they don't (I'm not sure that this
>> is good), then some of the commands will also need to be updated:
>> 
>>  1) "move" of VAGENDA no longer make sense.
>
>I agree - it would break that.

Ok, perhaps Im just having a tough time task switching between Real Work 
and CalSch Work but the definition of "move" starts with:

        The "move" command is used to move components within the CS's 
hierarchy of calendars. " 

I take this to mean that I would use a "move" to move my VEVENTS between 
different VAGENDAs (ie: Between my personal and work calendars).  Sounds 
like some folks have taken "components" to be other VAGENDAs.  I searched 
a chunk of the draft and the use of "component" always refered to VEVENT, 
VTODO, etc. 

If the use is _only_ intended for moving VAGENDAs around then the text needs to clearly state 
that to avoid confusion AND we should have some simple way to move 
calendar components between calendars w/in a CS (or among CS if your CS is 
so inclined but thats Fan Out...)

Since we are talking of replacing CHILD (I dont see CHILDREN in the latest 
draft) and PARENT with RELATED-TO and using the link type to quantify the 
link, what actually is non-sensical?  The linkage at the VAGENDA level 
applys to VAGENDAs only and not to calendar components (apples & 
oranges...) so moving calendar components around should be orthogonal to 
this and no breakage should occur.  (If I move my personal calendar from 
CS1 to CS2, it can and should still be linked to my spouses calendar on 
CS3; right??  The only issue may be if a reciprocal link exists but thats 
always a possiblity w/loose linkages)

>>  2) "create" of VAGENDA should always have top level container
>>     as target.
>
>Yes - And I don't like it.

Due to adding RELATED-TO as a property of the VAGENDA (something not 
reflected in the current restriction tables), when a new VAGENDA is 
created it can have a RELATED-TO (or multiple ones) and its created 
'linked' right off the bat.  The only 'extra' work would be to update the 
linked entity w/a correspdonding matching link if you are so inclined.  In 
any case, since RELATED-TO can be done on the "create", its not true that 
all calendars would be done at the top level.

>                   Others seem to disagree - I just want CAP OUT :-) !!!

I want it "done right" AND out.  We should learn from our iCalendar days 
(those old timers still here) and make sure we avoid as much ambiguity as 
we can but not design ourselves into a corner so when we do extend CAP we 
dont break it for older CAP clients/servers.

Bruce
===========================================================================
Bruce Kahn
INet: [email-masked]
Off to forage for some Cortaid and caffine...

---

From: Patrice Lapierre <[email-masked]>
Date: 10 Jan 2002 15:39:33 -0500

On Thu, 2002-01-10 at 12:07, [email-masked] wrote:
...
> a chunk of the draft and the use of "component" always refered to VEVENT, 

  In section 2.2 (Calendar Store Object Model). VAGENDA are defined as 
a component along with VEVENT, ... That seems logical since you can
create, search, modify, delete VAGENDA like other components.

  If I understand Doug's proposition to remove calendar hierarchy, what
would change is that VAGENDA would no longer be nested in the diagram of
section 2.2. Therefore in the absence of fanout the "move" command would
still apply to VEVENT, VTODO, ... but not VAGENDA. 

  I assume that a "modify" command would be used to set the RELATED-TO
property.

> all calendars would be done at the top level.

  Yes it should be possible to set the RELATED-TO property during the
creation of a VAGENDA. However since there would be no hierarchy in the
calendar store model the "target" would never point to another VAGENDA.

--
Patrice.