Subject: RE: SKICal CONTROL

From: [email-masked]
Date: Thu, 15 Mar 2001 11:41:02 -0500

Frank asked:
>I am
>also not certain what "legally responsible" actually means compared with 
the
>semantics for ORGANIZER, which is the person responsible for scheduling 
the
>event.

Here is the difference between ORGANIZER and CONTROL as I read it in Gregs 
text.  Your AA organizes travel plans (ie: makes your car and hotel 
reservations) for anyone you interview but you (or your company more 
likely) are the one legally responsible if someone you are hosting gets 
hurt on a site tour!.

In other venues like sponsored events (ie: The Boston Marathon) the 
ORGANIZER is just the one that coordinates, say, signups but is not 
necessarily the one (or the only one) legally or even financially 
responsible.  If The Boston Marathon gets postponed for some reason, the 
CONTROL entities would be the ones who are liable for 'making things 
right'.

Another example (American based, sorry non-US readers): In a recent 
Survivor II episode one of the people got pretty seriously injured and had 
to be helicopter transported to a hospital/burn unit.  The CONTROL could 
be the Executive Producers of the show as well as sponsors like ABC (is it 
ABC?) Networks, Target stores, Nike shoes, etc.  The ORGANIZER is simply 
the point of contact for organizing Survivors contestants and the other 
logistical stuff.

Perhaps "legally responsible" is not quite 100% on the mark but it seems 
relatively clear to me.

>Simple sounds good!

Yes!!  Thank you Greg!

>How many times can this property appear in a VEVENT? If more than once, 
what
>does this mean?

Boy, it seems more folks noticed this too.  Since you can easily have more 
than 1 "Sponsor" for an event you MUST have the ability to specify > 1 
CONTROL.  Since the value is a single URI, the only way to convey this 
mutiple sponsor info is to have > 1 CONTROL in the entity.

I assume that the CONTROL can be on any entity (except TIMEZONE or JOURNAL 
but JOURNAL is suspect).  But what does it mean if I have 2 VEVENTs (or 1 
VEVENT and 1 VTODO) and only one has CONTROLs on it and the other is 
RELATED-TO it?  Is there any "guilt by association" or is responsiblity 
ONLY valid if it specified on the entity?   A solid example of this:  1 
VEVENT for The Boston Marathon and 1 VEVENT for the "pre-Marathon Runners 
Dinner".  The latter is RELATED-TO the Marathon but only the Marathon 
VEVENT has any CONTROL information on it.  Does the pre-Marathon dinner 
'inherit' the CONTROL responsiblity?  Can it?  Should it?  For compactness 
I would suggest "yes" but this only works if the set of CONTROL entities 
are proper subsets of one another (ie: only some sponsors pay for the 
dinner but all pay for the marathon).  It does not work well for cases 
where some sponsors pay for JUST the dinner (ie: the local pasta company 
donates the food but gives no other sponsorship $$ or goods).  This makes 
me want to say that the CONTROL values are not 'inheritable'; they must be 
expressly put on all entities or they do not apply...  Hmm

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: "Greg FitzPatrick" <[email-masked]>
Date: Fri, 16 Mar 2001 14:06:28 +0100

relatively clear to me.

Well we used to say the "WhoDoUsue" Is that better?-)

Bruce:

>But what does it mean if I have 2 VEVENTs (or 1 VEVENT and 1 VTODO) and
only one has CONTROLs on it >and the other is RELATED-TO it?  Is there any
"guilt by association" or is responsibility ONLY valid >if it specified on
the entity?

RELATED-TO describes a relationship between calendar objects and is an
essential tool in 2445 for the coupling of multi-events.  They can not be
described otherwise.  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.

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!

But if you recall, the SKiCal group has submitted the property: PARTREL (see
below.)  This relationship differs from RELATED-TO as described below.

graphically:

		RELATED-TO
descriptor	<------->	descriptor
	|				|
	|	 			|
	v	PARTREL		v
   event	<------->	   event

To be frank, I don't remember us ever considering inheritance of values in
this scheme of things. I suppose that we took for granted that no
inheritances could be inferred.  Of course this is something you could solve
in XML with idrefs.

In any case I am glad the topic came up, we must always proceed with
caution:-)

<t>         Property Name: PARTREL     </t>
<t> Purpose: This property specifies another SKiSource, to which the
SKiSource being declared is related. This does not imply an inheritance of
properties from the external SKiSource given as a value but rather a
relevance.    </t>
					<t> Value Type: TEXT. (SKUID for another SKiCal/iCalendar object.)
</t>
<t> Property Parameters: Non-standard property parameters can be specified
on this property. It is RECOMMENDED that a Common Name parameter (cnparam)
be specified on this property.  </t>
<t> Conformance: This property CAN be specified within a "VEVENT" calendar
component.  </t>
<t> Description: This property allows for the publisher of a SKiSource to
indicate that the SKiSource is related to another SKiSource, such as a
festival or a package of tourist attractions. 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.</t>
<t> Format Definition: The property is defined by the following notation:
<figure>
							<artwork> partrel = "PARTREL" partrelparam ":" text CRLF
partrelparam  = *(      ; the following is optional,      ; but MUST NOT
occur more than once           (";" languageparam ) / (";" cnparam ) / (";"
reltypeparam) /           ; the following is optional,      ; and MAY occur
more than once           (";" xparam)      )  </artwork>
						</figure>
					</t>
					<t> Example: The following are examples of this property:  <figure>

artwork><![CDATA[ PARTREL;RELTYPE=CHILD;CN=Vattenfestivalen:<19990401T080045
[email-masked]>

PARTREL;CN=2004 Winter Olympics:<[email-masked]>

PARTREL;RELTYPE=SIBLING:<[email-masked]>      ]]></artwork>
						</figure>
					</t>