Subject: Re: New Topic: Export of calendar data and metadata

From: [email-masked] (Gilles Fortin)
Date: Wed, 12 Jan 2000 10:05:57 -0500

There is an issue that does not seem to me to have been properly addressed:
exporting holiday data. For interoperability it will be useful to
import/export holiday data.
This type of data is usually stored at the CS level and pertains to all its
users. Let's think of a school, which will follow national holidays, state
holidays, school board holiday and eventually special school events... Does
the iCalendar model take this into account?

>David Madeo wrote:
>>>
>>> [email-masked] wrote:
>>>
>>> >
>>> > Maybe I'm missing something here, but should it not be the
>>responsibility of
>>> > the client to ensure that there is an export capability.  It seems to
>>me
>>> > that all we need to declare is that an import/export capability be in
>>> > place.  Maybe we say it needs to be, at a minimum, ASCII format.
>>But, I
>>> > believe all we need to state is the capability must be there and it is
>>> > handled by the client software.
>>>
>>> I'd like to make sure that we define what an "export" is, regardless of
>>which
>>> client you happen to use.     CUA-1 exports just the calendar data, but
>>not
>>> the metadata.  CUA-2 exports both.    I've lost data if I'm using CUA-1
>>>
>>> I don't think this is a new function "EXPORT" or anything, though I'm
>>> interested if others think that is the way to go.  Personally, I
>>suspect it
>>> will be a paragraph explaining what it means to export/import a
>>calendar, and
>>> a list of queries.  The queries will extract a single calendar with
>>both the
>>> calendar data as well as the metadata.  If everyone uses the same
>>queries,
>>> then every product would produce identical export/import files, which
>>is a
>>> good thing.
>
>I agree, it should be possible for an administrative or super user account
>to fetch everything - given a VCAR. Or to set anything - given a VCAR.
>
>We would also need to explain that there would not be any kind if CS
>supported incremental backup or restore. That would be up to a custom
>CUA (or any CUA) to merge/mix/delete with a users help.  I see this part
>of backup the same as disconnected/reconnected issues.
>
>
>Content-Type: application/octet-stream; name="Doug.Royer.vcf"
>Content-Disposition: attachment; filename="Doug.Royer.vcf"
>
>Attachment converted: HD:Doug.Royer.vcf 16 (????/----) (00025796)
>Content-Type: application/octet-stream; name="smime.p7s"
>Content-Disposition: attachment; filename="smime.p7s"
>
>Attachment converted: HD:smime.p7s 9 (????/----) (00025797)

Gilles Fortin, Founder & President
__________________________________
Teamsoft Inc.
50 Queen, #304
Montreal, Canada H3C 2N5
+514-875-2231x106    fax:+514-875-2401
Internet: [email-masked]    Web: http://teamsoft.com

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Wed, 12 Jan 2000 17:43:45 +0100

This is a separate issue.  Ideally Holidays should be published as schemas
by the appropriate authority that has the power to declare them.  This is
very rare or should I say non-existent, though we think at least that we
have convinced  the Swedish government to let us do that for them.

Otherwise there are  volunteer efforts such as

http://www.holidayfestival.com/

which many planners use.  But again it is not an authoritive site - and all
the discussions which took place around the Olson time zone database apply
here as well. see thread: Timezones and Olson Tables

As Brian says in his disclaimer:

"I cannot guarantee the accuracy of any information given in any of the
pages from which this document has been called or of any page in the site
http://www.HolidayFestival.com. While every effort is made to achieve
accuracy, users should accept this for what it is, an attempt to gather
together in one place as much information as possible, however incomplete or
inaccurate it may be, in the hopes that it will be of some help to them.
Users make use of this information strictly at their own risk and are
advised to confirm it with their own contacts before traveling. Bankers and
those in the banking industry should be aware that, while every effort is
made to show accurate bank holidays around the world, they should
double-check the data with their own contacts before accepting it for
value-dating or other financial purposes."

I do not believe that anyone would like to indiscriminately fill their
CalApp with Holidays (someone at an IETF meeting told me there were 1236
public bodies with the authority to declare a holiday in California alone)
but that any event-publisher should have  access to immediate feed back on
any relevant holiday which occurs at a time and place coordinate matching
that of the intended event.

And the same goes for any calendar user planning attendance.

In any case the issue is not "Holidays" per se but "Schemas", since there
are many resources which in the future will receive "authoritive" addresses
and consequently  become part of the legal infrastructure.

In the SKiCal draft we refer to at least 14 desirable schemas, though we use
the term "lists".   Lists should be dependable, authoritive,
machine-readable, and so on...

http://www.ietf.org/internet-drafts/draft-many-ical-ski-01.txt

So stay tuned for Namespaces, schemas, paths, pointers and links in iCal V.5
(perhaps we will have gotten around to calling it xCal by then), but for the
time being, as phrased in typical CALSCH speak;
- It's not on our plate.

---

From: Doug Royer <[email-masked]>
Date: Wed, 12 Jan 2000 09:11:22 -0800

> the iCalendar model take this into account?

A CUA can ask for any type of data. Do you mean that you want
a special tag for HOLIDAY?

-Doug

---

From: John Stracke <[email-masked]>
Date: Thu, 13 Jan 2000 10:07:30 -0500

Greg FitzPatrick wrote:

> by the appropriate authority that has the power to declare them.

Except that not everybody observes all official holidays.  For example,
Presidents' Day is an official U.S. holiday, but most companies don't take it
off.  So you probably need to get your holiday data from some more local source
maybe one that filters the official data.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |Dave Barry for President! He'll Keep Dan Quayle.|
[email-masked]|(OK, it's old)                                  |
\=================================================================/