Subject: RE: multiple calendars-multiple instances

From: [email-masked]
Date: Wed, 3 Nov 1999 13:56:15 -0500

Greg:
Last comments...
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.
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. 
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?
-- Frank

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Thu, 4 Nov 1999 11:42:31 +0100

Frank wrote:
Last comments...
Why is SKiCal using .... "Place-Name" instead of "LOCATION". This seems an
unnecessary difference.

Greg answers:

Place-Name is not a "instead of" it is the name of a place or location which
is assumed to be public knowledge, for perhaps 90/10 of the calendar's
users.

The City of Stockholm is preparing machine-understandable list of all the
"Place Names" in the city, including schools, hospitals and parks.  It is
our intention that the value tagged by Place-Name will be the pointer to
these Schemas and return more detailed information to those who need it.

We are suggesting to companies looking at SKiCal, that they would create
such a list/schema for all named resources in their domain.

Thin Clients enjoy!

Sure we can do this in iCal, we have URL parameters,  but I haven't seen the
discussions on this.  I assume you are familiar with the XML Path Language
work which fully supports XML namespaces, where mechanisms like this are
being discussed.

Greg