Subject: Re: RELATED-TO vs CHILD/PARENT

From: [email-masked]
Date: Wed, 9 Jan 2002 10:34:08 -0500

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

I planned to by now but have been tied up load balancing for the upcoming 
Lotusphere 2002.  Thanks.

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

Yep!

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

Exactly what we need I think. 

We will have to slightly tweak Section 4.8.4.5's text a bit since it 
expressly says "between one calendar component and another" and we are going to logically extend that to be "between one calendar component and another or between calendars".  Should we make it clear that a Calendar cannot link to, say, an Event 
and visa versa?? 

Another slight change may be the data type defined for use by RELATED-TO. 
Currently its only "TEXT" but for CAP when 'linking' calendars, we would 
want the value to be a CalID (relative or fully qualified) instead of just 
any value (or at least it MUST be interpreted as a RelCalID or CalID at 
the "calendar level". 

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

And it gets rid of any mental bagage folks may have about what 
"hierarchical calendars" mean to them.

Bruce
===========================================================================
Bruce Kahn
INet: [email-masked] (<<====NEW EMAIL ADDRESS IN EFFECT)
Phone: (Changing too as I type.. )
Standard disclaimers apply, even where prohibited by law...

---

From: "John Stracke" <[email-masked]>
Date: Wed, 9 Jan 2002 10:47:57 -0500

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

This sounds like a good idea, *provided* we can make sure we don't 
conflict with what iCalendar means by RELATED-TO.  RELATED-TO on VAGENDAs 
is undefined (since they're not in 2445); but, on VEVENTs and other 
components defined in 2445, it already has semantics of its own:

   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.

So, the only components that can safely use RELATED-TO as an arbitrary 
heirarchy mechanism are those defined in CAP; we can't, for example, 
specify that a VEVENT has a RELATED-TO:RELTYPE=PARENT pointing to the 
containing VAGENDA.

/===========================================================\
|John Stracke                   |Principal Engineer         |
[email-masked]  |Incentive Systems, Inc.    |
|http://www.incentivesystems.com|My opinions are my own.    |
|===========================================================|
|"What we have here is a failure to assimilate." --Cool Hand|
|Locutius                                                   |
\===========================================================/

---

From: "John Stracke" <[email-masked]>
Date: Wed, 9 Jan 2002 10:58:08 -0500

>2) The CHILDREN/PARENT properties are "automatically managed" 
>   by the CAP server

I don't believe they are, actually; that would be inconsistent with the 
statement that they have no semantics on the CS.

/================================================================\
|John Stracke                   |Principal Engineer              |
[email-masked]  |Incentive Systems, Inc.         |
|http://www.incentivesystems.com|My opinions are my own.         |
|================================================================|
|He wondered if Elli was going to buy that explanation. His taste|
|for heavily-armed girlfriends did have its drawbacks.           |
\================================================================/

---

From: [email-masked]
Date: Wed, 9 Jan 2002 11:07:07 -0500

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: [email-masked] (<<==== NEW EMAIL ADDRESS IN EFFECT)
Phone: (No clue yet...)
The implants only itch if you think about them...

---

From: "John Stracke" <[email-masked]>
Date: Wed, 9 Jan 2002 12:15:30 -0500

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

Just like in hypertext.  Most pre-Web hypertext systems attempted to 
enforce link consistency, which required either a single server or a 
complicated distribution model.  When the hypertext community saw the 
early Web, they asked, "So how do you prevent broken links?".  Answer: "We 
don't.  It usually works, though."  "Usually" turned out to be good enough 
to live with, and the simplicity made Web servers easy enough to become 
common.

/=======================================================\
|John Stracke                   |Principal Engineer     |
[email-masked]  |Incentive Systems, Inc.|
|http://www.incentivesystems.com|My opinions are my own.|
|=======================================================|
|I'm a .sig virus...and, boy, am I tired!               |
\=======================================================/

---

From: "John Stracke" <[email-masked]>
Date: Wed, 9 Jan 2002 13:17:04 -0500

>  Tiny proposition, would it be more consistent with iCalendar 
>to use ';' (instead of '.') as a delimiter for parameters?

(a) The "." isn't really inconsistent with iCalendar, because iCalendar 
never references parameter values, it just states them.  Personally, I 
prefer the period, as being more like the familiar C or Java syntax for a 
field value.

To extend the analogy a bit: note that C doesn't use "." in separating 
field values in a struct initializer:

struct {int x, char* y} foo={12, "fred"};
int bar=foo.x;

The only problem I see with "." is that, in a SQL statement, it looks like 
the "table.column" syntax for use in a join.  It might become ambiguous if 
somebody defines a property for VALARM named, say, VEVENT, which has a 
parameter named UID (a backpointer from VALARM to the event that contains 
it):

SELECT * FROM VEVENT, VALARM WHERE VEVENT.UID=VEVENT.UID;

Obviously, this is contingent upon somebody getting careless about the 
properties they define; but it could happen (especially since, under our 
current process, it requires only one person to get careless; the Method 
Reviewer's decision cannot be appealed).  We could prevent the problem by 
using, say, "->" instead of ".", so that the above becomes:

SELECT * FROM VEVENT, VALARM WHERE VEVENT.UID=VEVENT->UID;

/=======================================================\
|John Stracke                   |Principal Engineer     |
[email-masked]  |Incentive Systems, Inc.|
|http://www.incentivesystems.com|My opinions are my own.|
|=======================================================|
|I'm not a bibliophile, I'm a bibliophiliac. Put me in a|
|bookstore, & my wallet bleeds.                         |
\=======================================================/

---

From: [email-masked]
Date: Wed, 9 Jan 2002 16:15:16 -0500

>specify that a VEVENT has a RELATED-TO:RELTYPE=PARENT pointing to the

This jives w/my comment eariler about only allowing linking between 'like'
critters.  Since RELATED-TO is defined as having a TEXT value, its possible
to have a VEVENT related to a Calendar just because the TEXT content was
not a UID but a CalID.  When updating 2445 (see prior posting) we need to
either expressly put in some text about "Components to Components only" and
"Calendar to Calendars only" so that some semblance of order remains....
Id love to see the result of a CalConnect Stress Test where a vEvent has a
RELATED-TO that just happens to be a CalID and some poorly done CUA
mistakenly links the Event to the Calendar instead of another Event w/that
UID.

Bruce
PS: Im getting goose bumps when it John and I agree on something so easily.
Sheesh, thats 2 times in as nearly as many months.  What is the WG coming
to? ;^)
===========================================================================
Bruce Kahn
Standard disclaimers apply, even where prohibited by law...

---

From: "John Stracke" <[email-masked]>
Date: Thu, 10 Jan 2002 10:49:48 -0500

>> No, it isn't.  "ATTENDEE.PARTSTAT" looks like "tbl.col",
>> syntactically, but its meaning is completely different; it's more
>> like "col.subcol".  The original example:
>> 
>> SELECT * FROM VEVENT WHERE ATTENDEE.PARTSTAT = 'ACCEPTED'
>
>Are you saying that it is not valid SQL 'syntax'?
>
>Are you saying that it does not map directly into an
>implementaions schema?
>
>Both?

Both (although the latter I don't consider important; you'll always have 
to remap), plus it's not valid SQL semantics.

Two months ago I might not have said anything; but I know SQL better now, 
having spent the past two months building a specialized SQL parser.  :-)

|Sleep is for wimps--healthy, well-adjusted wimps, but wimps|
|nonetheless.                                               |

---

From: "John Stracke" <[email-masked]>
Date: Thu, 10 Jan 2002 11:03:40 -0500

>Would you be happy with what Patricel suggested?
>
>        PARAM(ATTENDEE,'PARTSTAT')

I'd be somewhat unhappy with it, because (a) it's less convenient than 
ATTENDEE.PARTSTAT, and (b) it sort of implies that the second parameter 
can be any string-valued expression--and a variable expression would be 
impractical to compile into SQL-92.

|I will not buy this .signature, it is scratched.       |

---

From: "John Stracke" <[email-masked]>
Date: Thu, 10 Jan 2002 11:13:14 -0500

>When updating 2445 (see prior posting) we need to either expressly put in 
some text
>about "Components to Components only" and "Calendar to Calendars only" so 
that
>some semblance of order remains.

Yes, that sounds like a good idea.

|Stock up and save! Limit one.                          |

---

From: Alan Davies <[email-masked]>
Date: Thu, 10 Jan 2002 18:49:43 -0500

At 04:42 PM 10/01/2002 -0500, John Stracke wrote:
>I'm starting to think that SQL might be both too powerful (joins) and too
>crude (limited data types) to serve as a query language for CAP.

Yes, it's becoming hard to see what is gained by it's
added complexity, given it's limitation in representing
our data model.

--Alan

---

From: "John Stracke" <[email-masked]>
Date: Fri, 11 Jan 2002 10:15:52 -0500

>> >"Type of properties"? There is no type of property that
>> >can not be stored into SQL that we have defined.
>> 
>> Well, obviously, all the iCalendar properties can be stored as
>> strings...
>
>True, but we are not specifying that you use an SQL engine for
>the backend store. So that becomes implementation specific.

Forget the backend store.  We are using SQL to query the CS, and that 
means that the only data types that can appear in a query are SQL types.

/=============================================================\
|John Stracke                   |Principal Engineer           |
[email-masked]  |Incentive Systems, Inc.      |
|http://www.incentivesystems.com|My opinions are my own.      |
|=============================================================|
|Seen in computer peripheral ad: "User-friendly dip switches!"|
\=============================================================/