Re: RELATED-TO vs CHILD/PARENT

[Bruce_Kahn@xxxxxxxx]

Doug replied:
>Shannon wants to be able to have children of one calendar
>that DO NOT name the same parent, or name no-parent.

Making and enforcing 'bi-directional' relationships may not always be possible.  I, as a drone CU of IBM now, do NOT have sufficient rights to modify the "Entity formerly known as Iris Associates" calendar to include a CHILD link to my personal calendar.  I DO have sufficient rights to modify my own calendar to indicate that it is a CHILD of the larger collectives calendar.  

This same kind of restriction can happen between organizations.  For example, The United Way funds several community service groups so those groups may want to create linkages back to some United Way calendar (ie: A local community activities calendar for my area).  It is not acceptable to mandate that any CHILD MUST have a corresponding PARENT link on the other side.  We didnt mandate this in iCalendar and I dont think we can mandate it for calendars.

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

Thats what we accepted when we designed RELATED-TO the way we did originally.  When linkages are between entities whose control is not under a single or common UPN (ie: CU) then its just not possible to guarantee that going "top down" will result in the same view of the links as going "bottom up".

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

Ill keep saying it until it sinks in: Unless linkages are ONLY between calendars that a CU controls, it is NOT possible to guarantee that 'tight' linkages can be created.  

As such, CUAs have to be flexible in building "maps" of calendars via RELATED-TO.  This applied to Events/ToDos/Journals and it equally applys to Calendars.  I can easily create a ToDo for myself that is RELATED-TO the next IETF CalSch WG meeting that the IETF Registrar is ORGANIZER for.  The same 'loose' links between calendars are equally valid.  (See above.)

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

Unless we expressly mandate that ONLY RelCalIDs are allowed on RELATED-TO (Im AGAINST that) then a new parameter is not necessary. So far that was not proposed (but perhaps it was implicitly assumed by some given PARENT/CHILD were only w/in a CS).  RELATED-TO on calendars would have a value that is a CalID and as such I would expect that to be ANY valid CalID (RelCalID or Qualified CalID).

If we did not allow Qualified CalIDs (ie: CalIDs to calendars in other CSs) then building links between:

1: My calendar and my organizations or companies
2: My calendar and my spouses at another company entirely
3: My calendar and the IETF one (or the WGs for CalConnects)
4: Two different but cooperating organizations or groups (ie: United Way and The American Red Cross)

would not be possible since in none of these cases do the calendars realistically reside w/in the same, single CS.  (Im sure the SKiCAL folks would just love to have all interrelated calendars mandated to be on 1 central server in order to link the calendars...)  

Bruce
===========================================================================
Bruce Kahn
INet: Bruce_Kahn@xxxxxxxxxxxxxxxx (<<==== NEW EMAIL ADDRESS IN EFFECT)
Phone: (No clue yet...)
The implants only itch if you think about them...