Subject: RE: multiple calendars-multiple instances

From: [email-masked]
Date: Wed, 3 Nov 1999 13:21:28 -0500

Greg:
I think that your definition of "What=DESCRIPTION" should actually be 
"What=SUMMARY" because SUMMARY is required but DESCRIPTION is optional in 
an iCalendar VEVENT object. Right?
-- Frank

---

From: [email-masked]
Date: Wed, 3 Nov 1999 13:46:26 -0500

Greg:
The subsequent slide begin, "This is a polyphonic SKiCal object. It also 
describes two instances but it needs new variances...For example Ronald 
McDonald appearing at two different restaurants at 7pm and 9pm."
Why can't this be supported by iCalendar too? Is it only the issue of 
indeterminant DTSTART/DTEND for VEVENTs? I think that this an incorrect 
assertion too. Right?
-- Frank

---

From: [email-masked]
Date: Wed, 3 Nov 1999 13:37:04 -0500

Greg:
One slide is a little misleading. It says:
"This is also a duophonic Cal (sic?) object. It describes two 
"identifically descripted (sic?)" WHATS, occuring at the exact same WHEN 
in two different WHERES. For example, if Ronald McDonald was to make an 
appearance in two restaurants at the same time. This can not be described 
in iCal without using the mechanism of related objects."
The implication is that iCalendar can't do this and is deficient. The use 
of RELATED-TO property is not an enhancement or add-on to iCalendar. It is 
an integral part. Hence, iCalendar CAN SUPPORT THIS topology. Where is the 
beef?
-- Frank

---

From: "greg fitzpatrick" <[email-masked]>
Date: Wed, 03 Nov 1999 20:44:59 +0100

Right!  What=SUMMARY is correct  
1 - 0  Frank!

Greg

----------
From: [email-masked]
To: "Greg FitzPatrick" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: multiple calendars-multiple instances
Date: ons 3 nov 1999 19.21

Greg: 

I think that your definition of "What=DESCRIPTION" should actually be
"What=SUMMARY" because SUMMARY is required but DESCRIPTION is optional in an
iCalendar VEVENT object. Right? 

-- Frank

---

From: "greg fitzpatrick" <[email-masked]>
Date: Wed, 03 Nov 1999 21:16:48 +0100

Frank

The beef is that it takes two objects.  In earlier correspondence you have
pointed out that sometimes two objects can be of advantage.  You have also
pointed out that the database generating these two objects need not be
formed as the objects it is generating, i.e. there could be one database
entry generating two or more objects.  I have no "beef" with that.  

Remember this is just a simple example.  About the most simple example of a
polyphonic calendar object I could think of.  As objects grow in complexity,
it is my belief that we will reach a point, whereas a strew of  related
objects will become "bulky".  

Polyphonic calendar objects representing multiple instances, utilizing the
mechanism of conditional qualifiers zzzzzzz:-) will be streamlined for thin
client applications.
The need to generate a new calendar object for every event instance other
than those generated by recurring times, is not optimal to multi-instance
calendars.

At least, that is what I believe.

In January, Johan Hjelm of the WAP Forum will be organizing a live
demonstration with SKiCal over WAP, where we will be checking transfer times
for some rather complicated calendar objects.  At that  public event, I will
hope to prove what I claim.

If I am wrong - I will be the last one to admit it:-)

Greg
         
----------
From: [email-masked]
To: "Greg FitzPatrick" <[email-masked]>
Cc: [email-masked]
Subject: RE: multiple calendars-multiple instances
Date: ons 3 nov 1999 19.37

Greg: 

"This is also a duophonic Cal (sic?) object. It describes two "identifically
descripted (sic?)" WHATS, occuring at the exact same WHEN in two different
WHERES. For example, if Ronald McDonald was to make an appearance in two
restaurants at the same time. This can not be described in iCal without
using the mechanism of related objects." 

The implication is that iCalendar can't do this and is deficient. The use of
RELATED-TO property is not an enhancement or add-on to iCalendar. It is an
integral part. Hence, iCalendar CAN SUPPORT THIS topology. Where is the
beef? 

-- Frank

---

From: "greg fitzpatrick" <[email-masked]>
Date: Wed, 03 Nov 1999 22:46:01 +0100

Frank writes:
Why is SKiCal using different property names for the same semantics we have
in iCalendar. For example, "Title" instead of "SUMMARY" or "Place-Name"
instead of "LOCATION". This seems an unnecessary difference.
Greg, discouraged, answers:
 This hurts - it makes you wonder if anyone ever reads what we write!  TITLE
is not SUMMARY, TITLE tags the name of an Event.  P?r Lanner^ from our
working group wrote about this just two weeks ago.  A tittle often gives a
very poor indication of what an Event is about.  P?r cited some examples
from New York art shows.  The publishers that advise our WG have asked for a
specific field for TITTLE and we have provided them with that. 
To reach the same precision in iCal you would need to insert a property
parameter named TITLE into the SUMMARY.  I have never seen anyone supporting
this.  
Frank continues:
Use of "Venue" for a category of event seems to be also an unnecessary
difference. You should identify a ";LocType" parameter on "LOCATION"
property, rather than diluting the semantics of "LOCATION" property.
Greg surmises:
Yes, I can see that.  Do we have a machine understandable constrained
solution for indicating the LocTypes  that VENUE covers;  Indoors, Outdoors,
Transit, TV, Radio and Internet?  I'm sorry if I have missed this.
Frank again:
The observations in this SKiCal presentation seem to focus on a preference
for how the properties are indexed in the server, rather than functionality
missing from the iCalendar format. This doesn't seem like a rationale for
any changes to iCalendar. Did I miss something? 
Greg replies:
You lost me there.  The slides are extracted from a larger presentation and
I chose them to show those who might have a problem visualizing the
structure of RFC2445,   specifically the relationships between multiple
instances.
Gosh, I don't know how to put it any better.   As calendar objects become
more complex, there is going to be ambiguity as to what property refers to
what instance.  One way to solve that is to keep objects monophonic and use
the mechanism of related-to,  as is the current  thinking in iCal.  We
believe that we can support polyphonic calendar objects in SKiCal.  Time
will tell.
Finally, as to why we use different property names.
We create the logical model of SKiCal using graphic representation.  We have
discussed doing this in UML in order to remain compatible with other
efforts, but we have not yet done so.
This logical model must then find a home in a variety of syntaxes such as
XML, RDF, LDAP and not least RFC2445.  We try to utilize a neutral unique
syntax in our logical models to avoid later confussion.  Hence the DITS and
the DOTS and so forth.
When we apply this model to RFC2445 our rule is to look first to the syntax
available and try to use it.  When confronted with the choice of "bending"
iCal or creating new tags, we tend to support the latter alternative in
order to avoid ambiguity.
Greg

---

From: "greg fitzpatrick" <[email-masked]>
Date: Wed, 03 Nov 1999 21:26:03 +0100

Frank
You might be right.  The extremely unconstrained syntax of LOCATION might
allow a lengthy list of localities and addresses for a virtually identical
WHAT.  If that is so, I will change that slide accordingly.

Greg      

Frank wrote: 

-- Frank