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

From: [email-masked]
Date: Fri, 11 Jan 2002 12:23:42 -0500

Patrice wrote on 01/10/2002 03:39:33 PM:
>   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.

Reread my postings again.  There are multiple references to "components" 
and they do not all agree.  The prose in several spots disagrees w/each 
other and the text under 1.3's defintion.  Depending on where you search, 
you get a different notion... (The CAP editors need to do some phrase 
searching and matching/cleanup).

>   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. 

He said a 'F' naught word!!  :^b

I agree that "move" applies to all but VAGENDA now because we got rid of 
'F' for CAP v1.  Lets be safe and make sure that we clearly state that a 
CAP v1 CS should/must reject a 'move' on a VAGENDA so that if somone makes 
a bad CAP v2 CUA that tries it on an older CS, it wont cause a crash or 
other serious probelm.  (Someones gonna try it as an attack, count on it.)

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

Yep.

>   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.

You had me up until that last line.  We are replacing hierarchy w/a 
linkage model and the TARGET can be any VAGENDA since the value can be any 
CalID.  So can you clarify what that last line meant??

Bruce
===========================================================================
Bruce Kahn
INet: [email-masked]

---

From: Patrice Lapierre <[email-masked]>
Date: 11 Jan 2002 14:00:07 -0500

> CalID.  So can you clarify what that last line meant??

  After removing calendar hierarchy, the diagram of section 2.2 would
become:

CALSTORE
     |
     +-- VCARs
     +-- VQUERYs
     +-- VTIMEZONEs
     +-- VAGENDA
     |     |
     |     +--VEVENTs
     |     |    |
     |     |    +--VALARMs
     |     +--VTODOs
     |     |    |
     |     |    +--VALARMs
     |     +--VJOURNALs
     |     +--VCARs
     |     +--VTIMEZONEs
     |     +--VQUERYs
     |     |   ...

(I removed the VAGENDAs in VAGENDA).

A target can be a VAGENDA (calid) or the CALSTORE itself.

Based on the diagram (and my understanding of create):

   When creating a VQUERY, the target can be the CALSTORE or a VAGENDA.
   When creating a VEVENT, the target can only be a VAGENDA.

  Now since VAGENDA are no longer nested in VAGENDA, when creating a
VAGENDA the target is now limited to the CALSTORE.

NOTE: I don't have any problem with this, I just wanted to point out
some of the side effects.