Subject: RELATED-TO vs CHILD/PARENT

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

I talked to Bruce the other day on the phone. We were
trying to understand each others point.

(1) Bruce wants to rename PARENT/CHILD to RELATED-TO just like
    in iCalendar. I don't see a problem with that.

(2) People seem confused and think that you can not have
    parent child calendars without inherited VCARS.
	- they are wrong.

So, I propose (I was expecting Bruce to do this - he is busy):

We remove ALL words in CAP that are causing confusion. We
remove the words 'hierarchy', 'parent' and 'child' and replace
them with something like 'RELATED-TO' and tweak the text
to make it understandable.

Then, we delete the PARENT and CHILD calendar property
and replace them with the multi instances property 'RELATED-TO'
that can have the values 'PARENT', 'CHILD', and 'SIBLING' as defined
in RFC-2445 section "4.8.4.5 Related To" and section "4.2.15
Relationship Type" and specify that it is how one calendar is tagged
as relating to another calendar.

Then when these other (not yet proposed) relationship types are
defined, they can be added later. And CAP works now.

I don't think this changes any of the implementation specifics
from CHILD/PARENT, but it should clear up the confusion.

Comments?

---

From: Patrice Lapierre <[email-masked]>
Date: Tue, 08 Jan 2002 17:41:36 -0500

I like the idea, the use of 'RELATED-TO;RELTYPE=PARENT|CHILD' in
VAGENDA seems more consistent with the other iCalendar component. 

There are however two potential issues that I can see:

1) Currently VQUERY can not express condition on parameters.

      This may not be to big of an issue:
      
          a) The "source" element with depth=0 could be used to 
             search for immediate children, and the parent component 
             can be retrieved by at most an extra "search".

          b) If need be, the query language should probably be 
             extended to allow condition on parameters rather than 
             designing the component based on missing functionality.

2) The CHILDREN/PARENT properties are "automatically managed" 
   by the CAP server (e.g. based on the target element of the 
   "move" and "create" command of VAGENDA).

   This is not a problem by itself, the RELATED-TO component
   could also be "automatically managed" by the server.

   However, if in the future we introduce new values for 
   RELTYPE that can be "modified" be a CUA, it might complexify 
   the restriction tables for the "create" and "modify" commands
   (i.e. can set RELATED-TO iff it parameter RELTYPE is not
         PARENT, CHILD or SIBLING).

---

From: Doug Royer <[email-masked]>
Date: Tue, 08 Jan 2002 16:36:36 -0700

> 1) Currently VQUERY can not express condition on parameters.

It is missing - good point. We agreed it would look like
this - but it was never written down and is not in the ABNF.

	SELECT * FROM VEVENT where ATTENDEE.PARTSTAT = 'ACCEPTED'

>              can be retrieved by at most an extra "search".

I would hope that we take the CAP stuff out of the BEEP transport
layers and place it back into CAP data.

I am not sure IF I want depth searches, but if they are in
lets put the data for the CS back into the CS data (between
the BEGIN/END) and not in the BEEP transport commands.

We worked VERY hard to separate transport commands from CAP
DATA. Lets not put it back in because we are using BEEP.

We transport a CAP command with BEEP. If we put too much
into BEEP and not in CAP, we then have a mess when we
want to later allow the CAP commands or whatever we
invent later to be transported via iMIP-version-next.

Don't forget some CUA's will be mapping between iMIP
and CAP. If we put too much in BEEP, we just have to
invent a way to do it in iMIP - lets keep them in BEGIN/END.

>              designing the component based on missing functionality.

I agree (see above example).

>          PARENT, CHILD or SIBLING).

Shannon wants to be able to have children of one calendar
that DO NOT name the same parent, or name no-parent.
We would have to agree that a CUA can not traverse any
tree based on the RELATED-TO properties unless the CU
owns the tree and he CUA knows what that means. A visiting
CUA could try, but yes - we loose what child/parent means when
we switch to RELATED-TO and do not tightly couple them.
I want tight coupling between RELATED-TO:CHILD and RELATED-TO:PARENT.

Shannon does not want tight coupling between PARENT/CHILD
Others? time to comment!

I want to later add a EXTERN parameter to the RELATED-TO
property that allows links outside the CS (when we do fan-out).