Subject: Re: Proposed removal of hierarchy from CAP

From: "John Stracke" <[email-masked]>
Date: Tue, 8 Jan 2002 10:27:23 -0500

>certainly gain our endorsment as a group
>scheduling vendor.

Vendor endorsement is irrelevant in the IETF.

/=======================================================\
|John Stracke                   |Principal Engineer     |
[email-masked]  |Incentive Systems, Inc.|
|http://www.incentivesystems.com|My opinions are my own.|
|=======================================================|
|This sentance has threee errors.                       |
\=======================================================/

---

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

>I think that its implementation is the same for CHILD/PARENT
>and adds the SIBLING that Bruce wants (A NOP as far as I am
>concerned).

I'm not sure that SIBLING is a NOP.  It seems like its value would be in 
being able to take "a CHILD b && a SIBLING c" and infer "a CHILD c"--but 
you can't express that in a VQUERY, since you'd have to do recursion; so a 
CUA that wanted to find all the children would have to make an unbounded 
number of queries--expensive.

Bruce, can you explain what you'd use SIBLING for?

/=================================================================\
|John Stracke                   |Principal Engineer               |
[email-masked]  |Incentive Systems, Inc.          |
|http://www.incentivesystems.com|My opinions are my own.          |
|=================================================================|
|"If nobody believes what I say, I feel ineffective." "Oh, I don't|
|believe that."                                                   |
\=================================================================/

---

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

>and that should in turn help people actually implement the
>standard - especially when we have ONE "may" implement property

It's not so much that it's a MAY (I don't think it is; it's probably a 
mandatory part of 2445); it's that it doesn't take any work on the CS's 
part.  The RELATED-TO is just another property to store and query; it 
doesn't have any semantics for the CS.

/==========================================================\
|John Stracke                   |Principal Engineer        |
[email-masked]  |Incentive Systems, Inc.   |
|http://www.incentivesystems.com|My opinions are my own.   |
|==========================================================|
|"Where's your sense of adventure?" "Hiding under the bed."|
\==========================================================/

---

From: [email-masked]
Date: Wed, 9 Jan 2002 12:10:58 -0500

John replied:
>being able to take "a CHILD b && a SIBLING c" and infer "a CHILD c"

Not sure what family you grew up in but where I come from it doesnt read 
that way.  My son (CHILD) is Nathan and my Sister (SIBLING) is Michelle. 
Using your logic above you'd say that Nathan is a CHILD of Michelle. 
Sorry.  She is his Aunt; not is mother (even if she loves him like her 
own; it doesn't make it so).

However, I think we slightly bent the definition of SIBLING a bit...

>Bruce, can you explain what you'd use SIBLING for?

In iCalendar, we defined  SIBLING to mean a peer (see Sections 4.2.15 Relationship Type and 4.8.4.5 Related To). 

In CAP, its only slightly different since we are using different data 
entities; calendars instead of calendar components

Bruce
===========================================================================
Bruce Kahn
INet: [email-masked]  (<<=== NEW EMAIL ADDRESS IN EFFECT)
Actually, implants DO itch for a long time after initial insertion...

---

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

>Not sure what family you grew up in but where I come from it doesnt read 
that way

So I wrote it ambiguously.  I meant "a has a CHILD property pointing to 
b".

>In iCalendar, we defined SIBLING to mean a peer (see Sections 4.2.15
>Relationship Type and 4.8.4.5 Related To).

Yes, I did read that.  But iCalendar doesn't define "peer", so the obvious 
way to interpret it is to assume "SIBLING" means "sibling".  If that's not 
the intention, it should be either clarified or struck from iCalendar.

|News flash: Linux now implements RFC-1149, IP over Carrier|
|Pigeon!                                                   |

---

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

b".

...no, that's wrong, too.  Never mind; you knew what I meant.

/========================================================\
|John Stracke                   |Principal Engineer      |
[email-masked]  |Incentive Systems, Inc. |
|http://www.incentivesystems.com|My opinions are my own. |
|========================================================|
|Diplomacy: The art of letting someone else have your way|
\========================================================/