Subject: Re: Proposed removal of hierarchy from CAP

From: [email-masked]
Date: Thu, 27 Dec 2001 16:30:13 -0500

Doug replied on 12/27/2001 01:03:00 PM:

> > 1: Hierarchical calendars are currently defined for VCAR inheritance
> > and NOT content inheritance (Section 1.3):
> > 
> > The hierarchical calendar feature is not a storage relationship of the
> > calendars within the CS.
> 
> It is (at least logically).

Conceptually you may view it that way.  However, my citation (found below) 
was from the CAP spec, not from my imagination or personal opinion.  The 
only thing I added was the bold emphasis.  As such, hierarchical calendars 
as expressly defined as having no 'content' roll up (or other linkages) in 
CAP; its all for VCARs only.

> > Instead it is a feature that relates access
> > control rights to calendar content between different calendars in the
> > CS. The hierarchical relationship of a calendar is specified in the
> > "PARENT" and "CHILDREN" calendar properties.  (Emphasis is mine)
> 
> No PARENT / CHILDREN have nothing to do with the VCAR model.

They are not part of VCARs but they are the ONLY way that you can build 
hierarchical calendars for hierarchical VCARs!  Since CALIDs have no 
parsable meaning for conveying hierarchy (unlike your A.1, A.2.2, etc) the 
ONLY way you can build hierarchy is to have PARENT / CHILDREN links as 
attributes of the calendars.  That's how/why that property was added.

Besides, the quote I used was from Section 1.3 of the CAP draft.  The 
point being that the hierarchy exists only for VCAR equivalence checking, 
NOT for content roll up. 

> > 2: This feature was created originally to make some vendor(s) more
> > amenable to developing CAP due to how they intended to build it (ie:
> > using folders w/inherited ACLs).
> 
> No it was not. Calendar hierarchy was proposed (by me) in Dallas.
> VCARS (then VACL) were proposed by Frank and I later in Orlando. In
> Dallas we deferred ACLs because no one had a proposal and we
> agreed that even if ACLs did not make it into CAP, we needed
> calendar hierarchy.

I wanted to avoid eFinger(TM) pointing but...

Microsoft proposed hierarchical calendars so that they could build like 
they build "public folders" in Exchange and they rely on the folder ACL 
inheritance for access control.  When the WG discussed hierarchy we all 
agreed that building an architecture for content roll up ("full blown 
hierarchical calendars") was too much.  Most of this took place off the WG 
list that I recall (hall way talks and the like).  This may have occurred 
at the same times you raised the issue but I cant be sure.

The oldest reference to hierarchical calendar is Mark D. Anderson's posting of 21-Nov-1998 titled "capreq questions" and Andre's response the same date.  It contains:

4. calendar hierarchy and sub-calendars.

Sub calendars are a way to organize data elements in
a hierarchy manner. That is, a calendar can contains
components (Events, todo, journals, etc) as well as
calendars. A use for this would be to store your
kids baseball games in a sub calendar to yours.  This
is *Very* similar to files and directory.

Inheritance is not defined as a requirement and is
out of scope for the CAP definition.

You're response to part of that thread included:

                               Sub-calendars were meant
to be conceptually the same as file system directories.

(when talking about the actual hierarchical naming scheme actually) but 
the thread didn't actually cover restricting the hierarchy to VCARs and it 
focused on whether the names would be hierarchical or opaque, etc. 

Paul Hill revisited the issue on 9-Apr-1999 with is posting "(long) problems with CAP not having "users" and hierarchical calendars".  He did a pretty good job putting many of the hierarchy related issues 
into prose but unfortunately it did not generate virtually any WG traffic 
outside the participants already engaged in resolving the issue. 

I cannot clearly pinpoint the time when we chose to drop the concept of 
content roll up but I vaguely recall it happening at some meeting where 
lots of vigorous debate and hand waiving occurred.  (Issues like "When 
does content roll up occur?", "How is busy time searching affected (or 
effected) in hierarchical calendars?" etc all contributed to the agreement 
that no content roll up would occur.  Microsoft (Lisa or Tony?) was still 
pushing hard for hierarchical ACLs (VCARs) for the aforementioned reasons.

> >  Content was NOT included in the
> > 'roll up' because not all existing systems have that archictectural
> > concept and there are LOTS of issues w/content rollup that we
> > collectively did not want to try and bite off for the first pass.
> >  However this has long since become moot given the changes in
> > participation in the WG.
> 
> Yes - roll up was deferred at about the Dallas time.
> It was deferred because it was too complex at that time
> to debate without specific proposals (I do not think
> we have ever had any roll up proposed in any detail).

Ok, Ill buy the Dallas time frame. 

In any case, the current design for roll up is strictly for VCARs and it 
is causing some CAP complexities that I think can be resolved by simply 
removing the current hierarchy as Steve has mentioned.  Benefits of 
removing seem to outweigh the problems they cause.  That's my sentiments 
and I'm sticking to 'em...

> > Since hierarchical calendars are only for VCARs really, 
> 
> No they are not. The debate in Dallas had to do with having
> hierarchical calendar so people could organize separate 
> and unrelated or somewhat related events without cluttering
> their published accessible calendar. [Snip, snip]
> So that organizations (or persons) could have a hierarchy
> of calendars that represented their organization. 

I can buy that concept but it does not cover all kinds of 'relationships' 
between all calendars.  The use of a "League/Division/Team" kind of 
hierarchy example is logical for that kind of organization but it does not 
work for the "Husband/Wife" or 
"Mother/Father/Brother(s)/Sister(s)/Cousin(s)" model where no calendar is 
the "parent" really.

However I still think that removing hierarchy for VCARs is a very 
worthwhile change. 

I can see a case for keeping some kind of 'relationship' meta information 
on each calendar but I see no strong case for keeping it on VCARs yet 
(which is how Hierarchical Calendars are expressly defined)..

Also, your use of hierarchy is contrary to the definition of hierarchical 
calendar (see the original definition I cited) so perhaps you should 
propose some change text to include this design (above and beyond "access 
rights")

> 
> > I see removing
> > them a worthwhile design simplification given the benefits and the
> > cost of doing so.  (Of course I may regret those words in a couple
> > years but hey, its the holidays here so Im blissfully numb about it
> > now.)
> 
> I see removing VCAR inheritance as falling into that category.
> But I see calendar hierarchy as unrelated to that issue.

They are not unrelated given the definition of hierarchical calendars in 
Section 1.3.

> Removing VCAR inheritance - yes.

Great!

> Removing calendar hierarchy - no.

Then provide a more accurate description of Hierarchical Calendar that 
conveys this.  Its not how they are defined now (and why I didn't focus on 
the meta linkage which is related but not how we defined the linkage.

> I personally never liked VCAR inheritance. I hope it goes 
> away.

Sounds like all we need to do is redefine Hierarchical Calendars to remove 
access rights inheritance and to describe linkages a bit better then.  I'm 
not sure that only adding PARENT/CHILD is the right choice (How would I 
link to my peer calendars in my team or to the CAP Editors calendars using 
PARENT/CHILD only?)

Bruce
PS: Sidebar: If we remove VCAR inheritance and allow for "peer" 
linkages/relationships then do we really need to restrict the 'hierarchy' 
to being w/in the same CS?  After all, not all "Teams" in the "Division" 
may want to have their calendars on the same CS if they already have their 
own sites/systems (nor do I and my wife work at the same place)??
===========================================================================
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: Doug Royer <[email-masked]>
Date: Thu, 27 Dec 2001 16:40:58 -0700

[email-masked] wrote:
> Microsoft proposed hierarchical calendars so that they could build
> like they build "public folders" in Exchange and they rely on the
> folder ACL inheritance for access control.

Wrong - Frank, Steve and I talked Lisa and Tony into hierarchical
calendars in Dallas prior to that they were fighting them.
(Was this Pat's first calsch face-to-face meeting?)
They initially fought the idea with lots of emotion. In fact
Lisa Said (In Dallas):

	"Why would anyone want hierarchical anything [in calendaring]?"

For which I replied:

	"In MS-DOS Version 1.0, Microsoft did NOT have sub-directories
         in the file system. They added it later because people 
         wanted to organize themselves - same with calendars."

Lisa's predecessor (who's name I forgot - last name Dunn?) said
they had not decided if they were needed (in LA?).

Once they saw the advantage of them, then they went full steam
ahead and made the above proposals as you said.

**My real point being that it had NOTHING to do with VCARS as they
were not proposed in any detail at that time but were simply
put on the requirements document item list for CAP.

I don't know who added the definition of hierarchical calendars
being a product of VCARs to CAP - but it must have been
that editors views or understanding. That text should have
never been in CAP.

>  When the WG discussed
> hierarchy we all agreed that building an architecture for content roll
> up ("full blown hierarchical calendars") was too much.  Most of this
> took place off the WG list that I recall (hall way talks and the
> like).  This may have occurred at the same times you raised the issue
> but I cant be sure.

That was in Orlando  - later (did you go to the Dallas meeting?)

> The oldest reference to hierarchical calendar is Mark D. Anderson's
> posting of 21-Nov-1998 titled "capreq questions" and Andre's response
> the same date.  It contains: ...

Dallas pre-dated cap requirements, as Dallas was the first face
to face cap requirements meeting. Yes - Andre was in Dallas.
The reason behind the Dallas meeting was to document the participants
needs in order to propose the first cap requirements document which
came out later.

> I cannot clearly pinpoint the time when we chose to drop the concept
> of content roll up but I vaguely recall it happening at some meeting
> where lots of vigorous debate and hand waiving occurred.

It was prior to cap requirements being *accepted*. It may have been
mentioned, but there was never any specific proposal.

>  (Issues like
> "When does content roll up occur?", "How is busy time searching
> affected (or effected) in hierarchical calendars?" etc all contributed
> to the agreement that no content roll up would occur.  Microsoft (Lisa
> or Tony?) was still pushing hard for hierarchical ACLs (VCARs) for the
> aforementioned reasons.

Yes - they did want hierarchical ACLs. They wanted to model
it after the LDAP ACLs at that time. And that was after (and
had nothing to do with) hierarchical calendars. It was because
it would have fit into their LDAP schema.

> > ...
> In any case, the current design for roll up is strictly for VCARs and
> it is causing some CAP complexities that I think can be resolved by
> simply removing the current hierarchy as Steve has mentioned.
>  Benefits of removing seem to outweigh the problems they cause.
>  That's my sentiments and I'm sticking to 'em...

There is NO current design for roll up - none at all that
was dropped years ago. I am not sure I understand your point.

If you meant drop VCAR inheritance - Steve did not propose that,
he proposed that all child calendars go away. (Did I misunderstand
him?)

> I can buy that concept but it does not cover all kinds of
> 'relationships' between all calendars.  The use of a
> "League/Division/Team" kind of hierarchy example is logical for that
> kind of organization but it does not work for the "Husband/Wife" or
> "Mother/Father/Brother(s)/Sister(s)/Cousin(s)" model where no calendar
> is the "parent" really.

I agree. It does not cover all kinds of relationships. I do not
think they were ever designed to cover all kinds of relationships.

> However I still think that removing hierarchy for VCARs is a very

I agree. But Steve's proposal was to remove the ability to have
child ALL calendars. Steve did NOT propose removing VCAR inheritance
directly. He said by removing hierarchical calendars - the VCAR/MOVE
issue goes away (actually MOVE goes away as you can already rename
a calendar by MODIFY of the property name). And of course, VCAR
inheritance would go away as a side effect as there would be
no child calendars to inherit anything.

> I can see a case for keeping some kind of 'relationship' meta
> information on each calendar but I see no strong case for keeping it
> on VCARs yet (which is how Hierarchical Calendars are expressly
> defined)..

I would agree that it is how VCARs are defined. And I would
again propose (and I think maybe we are violently agreeing),
that VCAR inheritance goes away.

> Also, your use of hierarchy is contrary to the definition of
> hierarchical calendar (see the original definition I cited) so perhaps
> you should propose some change text to include this design (above and
> beyond "access rights")

That's what we are debating?
Removing this from 1.3 / Hierarchical Calendars and
tweaking the words:

Remove:
     ... Instead it is a
      feature that relates access control rights to calendar content
      between different calendars in the CS. 

> ...
> Sounds like all we need to do is redefine Hierarchical Calendars to
> remove access rights inheritance and to describe linkages a bit better
> then. 

Yes - I agree.

> I'm not sure that only adding PARENT/CHILD is the right choice.

It is already there - nothing to add?

> (How would I link to my peer calendars in my team or to the CAP
> Editors calendars using PARENT/CHILD only?)

No one has proposed any other linkage (other than CHILD/PARENT)
 - do you have a proposal :-)

> linkages/relationships then do we really need to restrict the
> 'hierarchy' to being w/in the same CS?  After all, not all "Teams" in
> the "Division" may want to have their calendars on the same CS if they
> already have their own sites/systems (nor do I and my wife work at the
> same place)??

Do you have a proposal?

As to CS <-> CS peer communication for cross CS peer relationships
- that I think falls into the category of fanout.
  Off topic and deferred for CAP 1.0

But I agree.

I had proposed years ago (in no detail) that a child calendar coul
be a pseudo link to another calendar in order to propose exactly
what you wanted. That was part of rollup - and was rejected or deferred.
I still think that can be done inside of an implementation and
not effect CAP at all. As long as it was ether:

	(a) Not visible outside the vendors implementation (CS + CUA).
   or
	(b) Looked to any non same vendor CUA as if it was just any other
	    child calendar.

I think the same is true for fanout. But I would like to see
the CS <-> CS interface agreed on some day.