Re: RELATED-TO vs CHILD/PARENT

[Doug Royer <Doug@xxxxxxxxx>]

Patrice Lapierre wrote:
> 
>   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.

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'

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

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.

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

I agree (see above example).

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

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

begin:vcard 
n:Royer;Doug
tel;cell:208-520-4044
tel;fax:208-552-1179
tel;work:208-520-4044
x-mozilla-html:FALSE
url:http://Royer.com/People/Doug
org:INET-Consulting LLC <http://INET-Consulting.com
adr:;;1795 W. Broadway #266;Idaho Falls;ID;83402;
version:2.1
email;internet:Doug@xxxxxxxxx
title:Chief Executive Manager
x-mozilla-cpt:;9152
fn:Doug Royer
end:vcard