RE: calendar *dependent* events scenarii

Hi Mark,

The point of the scenario isn't the usefulness index, although we would like for the service described to have some utility (and not be a meaningless example). The point is actually to draw a distinction between values that are point-moments in time (January 3, 1956 at 10:23:47 PM Pacific Standard Time---what in Java you'd call a java.util.Date) and "calendric" moments ("the Fourth of July", people's birthdate, etc--what in Java you might use a java.util.Calendar to represent)

These require slightly different data types in XML Schema and, of course, different handling in code.

But state holidays in Utah are a good example too.

Addison

> 
> 
> I don't know that the calendar scenario is actually that useful; 
> most OSs have a
> variety of calendars already. What would be a more compelling 
> example would be a
> server for 'business holidays', since those are not generally 
> supported, and
> vary by country and even by smaller units: states/provinces, even 
> cities; and
> may need updated frequently.
> 
> E.g. get me the state holidays in Utah.
> 
> Mark
> __________________________________
> http://www.macchiato.com
> ► शिष्यादिच्छेत्पराजयम् ◄
> 
> ----- Original Message ----- 
> From: "Addison Phillips [wM]" <aphillips@webmethods.com>
> To: <andrea.vine@Sun.COM>; <public-i18n-ws@w3.org>
> Sent: Mon, 2003 Nov 24 21:25
> Subject: RE: calendar *dependent* events scenarii
> 
> 
> >
> > Hi Andrea,
> >
> > Great stuff. Some suggestions on the intro and first scenario below.
> >
> > Addison
> >
> >
> > > 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 date is calendar-dependent but is not 
> 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.
> > >
> >
> > Perhaps "The value returned represents a specific date on the 
> calendar, not
> > a timestamp value as might be associated with a particular locale or
> > timezone."??
> >
> >
> > > Scenario A:  A service calculates the date for Easter, Passover, or
> > > Ramadan for any given year in a specified calendar type.  All these
> > > holidays are strictly calendar-dependent; they are calculated based on
> > > certain calendar and lunar events, as well as historical tables.
> >
> > I don't think the intro to Scenario A quite captures it. I 
> think we need to
> > draw the distinction with fixed-date events. Maybe:
> >
> > A service calculates the date for Easter, Passover, or Ramadan 
> for any given
> > year in a specified calendar type. These religious holidays are 
> partly based
> > on astronomical events (such as lunar phases) as well as 
> historical tables
> > and not strictly calendar dependent (in the way that many 
> secular holidays,
> > such as various national independence days or leader's birthdays are) or
> > predictable (third Thursday in November, etc.). Thus the need 
> for a service
> > to calculate the date might be necessary. // continue with... "The SOAP
> > request..."
> >
> > > The
> > > SOAP request would contain a holiday, a year, and a parameter 
> indicating
> > > the calendar type, e.g. "Gregorian".  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.  It may seem as though the calendar type is a part of
> > > the locale information, but locale information is typically associated
> > > with the end user, and there's far more information in a 
> locale than is
> > > needed. In this case, the calendar type is irrelevant to the locale,
> > > since the requester may be looking for information unrelated to user
> > > preferences or system settings.
> > >
> > >
> > >
> >
> >
>

Received on Tuesday, 25 November 2003 15:26:03 UTC