Subject: Re: SV: SKiCal CONTROL

From: [email-masked]
Date: Fri, 16 Mar 2001 11:53:09 -0500

[Caveat: somewhat long response and 1 digression included]

Greg answered:
>In the case where a particular property has a stated
>value in one object and a null in its related-to counterpart, then the
>inference that the stated value "overrules" the null or vice versa, would
>have to be made be by the interpreting application.

Let me clarify something about my frame of reference when I asked all 
those questions: in RFC 2445 the RELATED-TO is simply used for 'linking' 
entries to each other but NOT used for inheriting values.  Since CONTROL 
is something that has a very direct legal impact/use I wanted to see if it 
A) would inherit values (it was not clear or ruled out) and B) if so, just 
how should this be dealt with. 

The only useful text in 2445 about the use of relationship is:

   Changes to a calendar component referenced by this property can have
   an implicit impact on the related calendar component. For example, if
   a group event changes its start or end date or time, then the
   related, dependent events will need to have their start and end dates
   changed in a corresponding way. Similarly, if a PARENT calendar
   component is canceled or deleted, then there is an implied impact to
   the related CHILD calendar components. This property is intended only
   to provide information on the relationship of calendar components. It
   is up to the target calendar system to maintain any property
   implications of this relationship.

This is more than a bit vague and probably on purpose since not all C&S 
systems have the concept of 'linked' or related events so we cannot 
mandate it in the RFC.  The only real description of any kind of impact is 
changes like scheduling, not of value inheritance.   Im a bit unclear if 
the impact is bi-directional (ie: changes to the CHILD are reflected in 
the PARENT) but thats a digression 
<DIGRESSION TO ISSUES LIST>
Eric: Put these on the Issues List please.  Do we need all these linkage 
types if they have no real impact?  That is: If I know my PARENT and can 
get their CHILDren then why do I need a SIBLING since it has no impact on 
me?  Does a PARENT have to have a CHILD link on it too (or visa versa)? 
Perhaps the 1st line should be changed to:

   Changes to a calendar component referenced by this property can have
   an implicit impact on the related dependent calendar component(s).

and the SIBLING relationship removed (for simplicity reasons).  Also the 
following text is VERY misleading:
                                                      For example, if
   a group event changes its start or end date or time, then the
   related, dependent events will need to have their start and end dates
   changed in a corresponding way.

in that if the CHILD has its own distinct start/end date and time.  It MAY 
need to be updated at the users discression, not automatically so "will 
need to have" is not always true or accurate.
</DIGRESSION TO ISSUES LIST>

>Since this could create dual (or more) values for every single property,
>there are some potential collisions here that we should perhaps consider 
-
>and not just for CONTROL!

Being of the KISS mindset I think you should NOT add it in; you should 
require the data to be expressly put in ALL 'related' or "linked' entries. 
 That way there is no confusion or inaccurate assumptions made.

>This property differs from the
>RELATED-TO property of <xref target="refs.RFC2445">RFC-2445</xref>, since
>that property defines a relationship between calendar objects describing
>SKiSources and not between SKiSources themselves.

Im not groking your definition of a SKiSource compared to the entry 
represented by, say, a VEVENT in iCalendar.  So the distiction between 
RELATED-TO and  PARTREL is nonexistant to me.  Can you differentiate it 
better (at least for me)??

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: "Graham Gilmore" <[email-masked]>
Date: Wed, 21 Mar 2001 11:39:33 -0500

----- Original Message -----
From: <[email-masked]>
To: "Greg FitzPatrick" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: 16 March, 2001 11:53
Subject: Re: SV: SKiCal CONTROL

> get their CHILDren then why do I need a SIBLING since it has no impact
> on me?  Does a PARENT have to have a CHILD link on it too (or visa
> versa)?

    Two VCALENDAR components might be related with a SIBLING
relationship, without having any PARENT or CHILD relationship to any
other component (for example, 2 New Years' parties organized by the same
organizer in different cities linked with live video feeds).

    Graham