RE: RDF calendar schemas

An additional thing to consider, besides translations potentially being
offered for textual descriptions (presumably by the organizer of the event -
though perhaps a mechanism should exist to allow for translators who might
not be the organizer?) is that to fully deal with internationalization of
time related information more than just translations of descriptions will
need to be done.

Much of this should be doable by the client side software, however currently
iCal stores dates in a form that is derived from text strings - that is it
is a set of strings that are interpreted (numbers in a particular order,
optionally followed by a "Z" character to indicate UTC time, or with a
corresponding TZID string identifying that a TimeZone should be applied to
the time - for international purposes the representation of the dates should
be adjusted to match locale specific formating (commas vs. periods as
seperators, order of presentation of Month, Day, Year; abbreviations of
month names, day of week names etc, even ordinal markers (1st, 2nd etc.) all
of which vary from language to language)

More specifically, this is all fairly simple when moving data between
one-byte languages - most of the code that is written to manipulate the
strings, break them apart, convert them to the locale specific
abbreviations/names etc is not hard to write - and frequently system locale
information can be used to get the correct names (or alternatively locale
like string mapping can be loaded into an internationalized software). Where
is gets much trickier is dealing with multi-byte languages (mostly Asian
languages) where the underlying datastructures and hard coded assumptions
about separators, how many bytes between separators etc will all be very
different for double-byte languages.

One issue to also consider is the USE that the underlying data schema will
be put to - one consideration that iCal has tried to keep in mind is that
while an iCal formatted file is intended for a software package to interpret
and deal with, it is also written text with human understandable field names
and formatting - thus it can be (and often is) also read by a human to look
at the information (see also vCard's which are also meant for a computer
software to read and process, but are also written with humans in mind.)

However - both iCal and vCard (and vCal) were written mostly assuming
English - keywords used to separate information out are English words, and
the schema mostly assumes an ASCII format, single-byte, manner to depicting
the information. It is assumed that content may have fields in multiple
languages (indeed there is even a LANGUAGE property/parameter (have to look
up which) within the iCal specs - but the keywords identifying each iCal
section and the other underlying assumptions about how it will be dealt with
assume English. This is not necessarily a bad thing - but worth keeping in
mind.

So - do we care just about the content - and about having the ability to
store content in multiple languages (perhaps even in multi-byte languages)
or should we also look at the assumptions and structures underlying the
schema itself and not just the data that the schema might be called upon to
store?

Shannon

-----Original Message-----
From: www-rdf-calendar-request@w3.org
[mailto:www-rdf-calendar-request@w3.org]On Behalf Of brian moseley
Sent: Tuesday, June 05, 2001 10:27 PM
To: www-rdf-calendar@w3.org
Subject: Re: RDF calendar schemas


On Tue, 5 Jun 2001, Aaron Swartz wrote:

> Shannon J. Clark <shannon@jigzaw.com> wrote:
>
> > Five - will you have to handle multiple languages? Unicode and/or
multi-byte
> > languages?
>
> XML takes care of this for us.

xml takes care of specifying data in unicode, but how does
it signify that the textual description of an event is in
french?

Received on Wednesday, 6 June 2001 02:12:10 UTC