Re: calendar dependent events scenarii - now with less fat!

However much I might like the imaginative examples, I really think none of these are going to motivate the average reader of the document; one should come up with a real business examples, not something that will be interest only to scholars. I think in practice even the multiple calendars are not going to be of interest, since those will be hosted on most operating systems. Not unless you make the client in the scenario a small system, like a mobile phone. (Even then, in a few years I expect we'll see full-fledged OSes on those.)

I still believe a better example is business holidays. Unlike the calendars, those are *not* algorithmically predictable, they vary considerably by locality (e.g. Patriot Day in Utah), and one can construct a more real scenario (e.g. a fulfillment center catering to local governments needing to determine when their offices are able to receive shipments.)

Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄
 
  ----- Original Message ----- 
  From: Mike McKenna 
  To: public-i18n-ws@w3.org 
  Sent: Thu, 2003 Dec 04 09:15
  Subject: Re: calendar dependent events scenarii - now with less fat!


  A more realistic scenario might be a service that takes as input Carbon-14 dating information and returns contextualized calendar date ranges.  For example, what if you're working on an archeological dig in Mongolia and find remains from the Attilla the Hun (or one of his sons).  Whose calendar do you use to report the results?  There's the Gregorian Calendar for current reference, but if you want to map to historical docuemnts for context, there's the Chinese Imperial calendar, the Eastern Orthodox Calendar, the Roman Calendar, the Arabic calendar, and the Budhist calendar (the Huns really got around!)

  Cheers,

         Mike___

  Addison Phillips [wM] wrote:

65M years ago the day was only 18 hours long and there were over 400 days in the year. The month was also somewhat shorter. Tidal losses. Talk about your leap seconds. Maybe the dinosaurs all got giddy or their tiny little brains were overloaded by the need for calendar reform......

Ack. I think the idiocy infecting various lists (not this one) is getting to me. Please write as many different scenarios as you can. We need the material. :-)

Addison

Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International

Internationalization is an architecture. 
It is not a feature.

  -----Original Message-----
From: public-i18n-ws-request@w3.org 
[mailto:public-i18n-ws-request@w3.org]On Behalf Of Tex Texin
Sent: 2003年12月3日 22:57
To: andrea.vine@Sun.COM
Cc: public-i18n-ws@w3.org
Subject: Re: calendar dependent events scenarii - now with less fat!



This made me think of an interesting application. Astronomers and
Geologists, etc. might have reason to believe some event has occurred
historically and would like to confirm it thru historical reports. They
would need dates in the local calendar of the time.

For example, predicting a comet appeared n years ago, (or some seismic
or other event, for example a flood) scientists might want to check for
reports of a bright star etc. and need the dates as used at the time in
countries around the world....

What was the calendar used in gonawandaland (or pangea) 65M years ago
when dinosaurs were wiped out by the asteroid hit? ;-)

I can write up the age one, if people want.

I think it might be good to have something that is not just date
conversions (although under the covers age also is calendar conversion
too.)

let me know.
tex

"A. Vine" wrote:
    All,
Here is the updated updated calendar dependent events scenarii, 
      incorporating
    Addison's and Martin's comments.
Andrea

Scenario I-0?? Calendar-dependent events

A Web service is set up to calculate a calendar date and send it back to
the requester.  The value returned represents a specific date 
      on the calendar,
    not a timestamp value as might be associated with a particular locale or
timezone.  The service may need to take in information such as 
      the calendar
    type, year, and related descriptive information.

Scenario A:  A service calculates the date for Easter, 
      Passover, or Ramadan for
    any given year, returning a date value in {fill in the format, 
      I don't know the
    right wording here}. These religious holidays are partly based
on astronomical events, such as lunar phases, as well as 
      historical tables.
    They are not strictly calendar dependent in the way that many 
      secular holidays,
    such as various national independence days or leader's 
      birthdays are, nor are
    they predictable, for example, the fourth Thursday in November. 
      Thus the need
    for a service to calculate the date might be necessary.  The
SOAP request would contain a holiday and a year in ISO 8601 format.  In
addition, some other data may be required, such as for Easter 
      there may be a
    parameter specifying "Orthodox" or "Western".  The Web service 
      would in turn
    calculate the appropriate date and send a message back to the 
      requester with the
    calculated date.  Some other service may be used to convert the 
      returned date
    value into a specified calendar type, such as the Japanese calendar.

Scenario B:  A service calculates historical dates in different parts of
the world and returns an equivalent ISO 8601 date to the
requester.  The SOAP request would contain a date and its country of
origin.  For example, a request might have the date 1812/08/26 and the
origin "Russia".  Russia was using a different calendar from 
      places such as
    Italy or France at that time; what would appear as the same 
      date was actually
    several days off.  While this may look like it is part of the 
      locale due to
    the country of origin, it should not be treated as such.  Locales are
typically associated with the end user, not with a piece of data, and a
locale does not contain information on historical times.

Scenario C:  A service calculates Chinese New Year for any non-Chinese
calendar type.  The SOAP request would include a parameter with the
calendar type, such as "Gregorian", "Hebrew", or "Japanese Imperial".
The calendar type is again irrelevant to the locale, since the
requester may be looking for information unrelated to user preferences
or system settings. {in light of all the comments, I have no 
      idea what to do
    with this scenario.  maybe we should replace it with Tex's scenario.}
      -- 
-------------------------------------------------------------
Tex Texin   cell: +1 781 789 1898   mailto:Tex@XenCraft.com
Xen Master                          http://www.i18nGuy.com
                         
XenCraft              http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------
    


  

-- 
Michael McKenna
Globalisation Architect
mgm@globalisation.org

California Digital LIbrary
University of California Office of the President
michael.mckenna@ucop.edu
http://www.cdlib.org