Subject: Re: Proposed removal of hierarchy from CAP

From: [email-masked] (Gilles Fortin)
Date: Tue, 8 Jan 2002 09:44:37 -0500

I do think that removing the hierarchical calendar feature would simplify
the implementation of CAP, and certainly gain our endorsment as a group
scheduling vendor.

There are few cases where I see this feature useful, but many more cases
where it becomes a nightmare... just imagine asking a user to specify where
in the hierarchy he is entering a new appointment on his web phone!!!

I hope common sense shall prevail.

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://www.teamsoft.com

---

From: Doug Royer <[email-masked]>
Date: Tue, 08 Jan 2002 09:02:51 -0700

> I hope common sense shall prevail.

There was no requirement that you must implemnet this. As with
IMAP, you don't have to have sub-folders. But you can. 

-Doug

---

From: [email-masked] (Steve Mansour)
Date: Tue, 08 Jan 2002 12:30:29 -0800

Just so we're all on the same page, I believe the recommendation has boiled
down to this:

   * We keep the calendar (or should I say: VAGENDA) properties, CHILDREN and
     PARENT
   * We specify that VCARs are not hierarchical.  That is, there is no VCAR
     inheritance. Each calendar (VAGENDA) is self-contained with respect to its
     VCARs. There is one potential exception to this which is default VCARs
     which are specified at the data store root.  This provides one level of
     hierarchic VCARs and it applies to *every* calendar (VAGENDA).
   * There is no "roll-up" of events or todos. That is, if calid abc123 has a
     child calendar def456, then a request for events from calid abc123 will
     not contain any events from def456.

Doug, Bruce, George is this your understanding?

Is this approach acceptable to all?

-Steve

---

From: Doug Royer <[email-masked]>
Date: Tue, 08 Jan 2002 14:35:44 -0700

Steve Mansour wrote:
> 
> Just so we're all on the same page, I believe the recommendation has
> boiled down to this:
> 
>    * We keep the calendar (or should I say: VAGENDA) properties,
>      CHILDREN and PARENT

Or use RELATED-TO as proposed recently - acceptable?

I think that its implementation is the same for CHILD/PARENT
and adds the SIBLING that Bruce wants (A NOP as far as I am
concerned).

Plus it allows for other extensions in the future.

>    * We specify that VCARs are not hierarchical.  That is, there is no
>      VCAR inheritance. Each calendar (VAGENDA) is self-contained with
>      respect to its VCARs. There is one potential exception to this
>      which is default VCARs which are specified at the data store
>      root.  This provides one level of hierarchic VCARs and it applies
>      to *every* calendar (VAGENDA).

And the default VCARS are copied to *each* new calendar?
No matter how they are related to any other calendar - I agree.

And the same with decreed VCARs, they in effect are now
copied to every created calendar.

>    * There is no "roll-up" of events or todos. That is, if calid
>      abc123 has a child calendar def456, then a request for events
>      from calid abc123 will not contain any events from def456.

Until I (we - calsch -we?) propose a SEPARATE roll up draft :-)
Which several are interested in doing. --AFTER CAP--.

---

From: "Shannon J. Clark" <[email-masked]>
Date: Tue, 8 Jan 2002 16:27:00 -0600

The RELATED-TO w/Parameters is also a nice simplification of the PARENT and
CHILDREN properties.

1. It allows for greater flexibility - and the fairly clean potential for
flexible structures (i.e. possible multiple parents situations, as well as
new properties such as SIBLING)

2. By using a philosophy of defining an extendable, simple, and flexible
structure vs. adding many additional properties we simplify the overall
standard - and that should in turn help people actually implement the
standard - especially when we have ONE "may" implement property - vs.
multiple properties which have some "must" restrictions.

I for one find the RELATED-TO conceptually appealing.

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Doug Royer
Sent: Tuesday, January 08, 2002 3:36 PM
To: [email-masked]
Subject: Re: Proposed removal of hierarchy from CAP

---

From: [email-masked] (Steve Mansour)
Date: Tue, 08 Jan 2002 21:33:06 -0800

several comments below.

> I for one find the RELATED-TO conceptually appealing.

ok

> Plus it allows for other extensions in the future.

OK

> No matter how they are related to any other calendar - I agree.

hmm... whether they are copied or simply inherited should be clarified.  Seems
like copying them takes up more space -- but it does give us a well-defined
solution. That is, once you've created a calendar and you have the VCARs set up
the way you want them, you won't experience any unexpected behavior because
someone changed the root store VCARs.  This could be a good or bad thing
depending on your point of view, but I would vote for copying the VCARs into
the calendar.

> copied to every created calendar.

ok. I guess I was thinking that decreed vcars are vcars at the root store
level.

> Which several are interested in doing. --AFTER CAP--.

A separate roll-up draft sounds like the right approach. After CAP also sounds
like the right approach.
-Steve

---

From: Doug Royer <[email-masked]>
Date: Wed, 09 Jan 2002 10:14:55 -0700

Steve Mansour wrote:

> hmm... whether they are copied or simply inherited should be
> clarified.  Seems like copying them takes up more space -- but it
> does give us a well-defined solution. That is, once you've created
> a calendar and you have the VCARs set up the way you want them, you
> won't experience any unexpected behavior because someone changed the
> root store VCARs.  This could be a good or bad thing depending on
> your point of view, but I would vote for copying the VCARs into
> the calendar.

Great, the 'hmm' scared me :-)