Subject: CAP (Hierarchial calendars) - latest intem draft

From: Doug Royer <[email-masked]>
Date: Tue, 08 Jan 2002 13:22:48 -0700

In section 1.3

I propose we remove:

>   Hierarchical Calendars
>
>    A CS feature where a calendar has a hierarchical relationship
>    with another calendar in the CS.  The top-most calendars in the
>    hierarchical relationship have the CS as their parent.  There
>    may be multiple top-most calendars in a given CS.  Within a
>    given hierarchical relationship, all sub-calendars have a
>    calendar with a "parent" relationship.  In addition, sub-
>    calendars may have a relationship with another calendar that
>    has a "child" relationship.  The hierarchical calendar feature
>    is not a storage relationship of the calendars within the CS.
>    Instead it is a feature that relates access control rights to
>    calendar content between different calendars in the CS.  The
>    hierarchical relationship of a calendar is specified in the
>    "PARENT" and "CHILD" calendar properties.

And replace it with something like:

     Related Calendars

     A CS feature where a calendar has a relationship with another
     calendar. The relationship is specified in the calendar with
     the RELATED-TO calendar property. This relationship has no
     predefined meaning to CAP. It is a convince for the CUA, CU,
     or CS administrator so that calendars may be organized and
     marked as relating to each other as specified in the
     implementation or administrative configuration of the CS or
     CUA. Any CUA with sufficient access permission may view these
     RELATED-TO properties.

---

From: Patrice Lapierre <[email-masked]>
Date: Tue, 08 Jan 2002 18:10:00 -0500

> And replace it with something like:
... 
>       This relationship has no predefined meaning to CAP. 
>      It is a convince for the CUA, CU, or CS administrator so 
>      that calendars may be organized and marked as relating to
...

  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.
 2) "create" of VAGENDA should always have top level container 
    as target.
 3) the "depth" attribute of the "source" element should removed.

---

From: Doug Royer <[email-masked]>
Date: Tue, 08 Jan 2002 17:12:47 -0700

>  1) "move" of VAGENDA no longer make sense.

I agree - it would break that.

>  2) "create" of VAGENDA should always have top level container

Yes - And I don't like it.

>  3) the "depth" attribute of the "source" element should removed.

I don't recall any such proposal - I just noticed it appeared.

I agree. I was sending what I think almost everyone else is
saying. I would be happier if we changed CHILD/PARENT to
RELATED-TO and kept tight bindings. That is they must
exist within one CS [for now] and if you are a child,
it had better name you as its one parent.

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

-Doug