RE: [XSLT2.0] format-date() - country

Personally, I have some sympathy with your comments. I do have doubts about
whether people who want to manage dates in non-Gregorian calendars will
actually want to use the schema date/time data types, and about whether
there is any benefit in providing conversions from Gregorian dates to other
calendars without also providing conversion in the opposite direction. As an
amateur genealogist myself, I know that I would never choose to store
historical data using proleptic Gregorian dates. 

I think the goals are clear: we are trying to ensure that there is enough
flexibility to cover all the ways that dates are actually represented by
different communities. But your objection, that we haven't done the research
to actually show how the parameters to these functions will be used, is
quite valid.

The W3C process does demand that specs be proven to be implementable.

Thanks for the comment, and I'm sure there will be further debate in the
working group. As I'm sure you can guess, there has been a great deal
already.

Michael Kay


> -----Original Message-----
> From: Mikael Sterner [mailto:msterner@kth.se] 
> Sent: 27 November 2003 06:29
> To: public-qt-comments@w3.org
> Subject: [XSLT2.0] format-date() - country
> 
> 
> 
> I think that the country argument should be removed from the 
> date formatting functions in 16.5 of the XSLT 2.0 draft.
> 
> <http://www.w3.org/TR/xslt20/#lang-cal-country>:
> > The intended use of the country argument is to identify the place 
> > where an event [...] took place or will take place. [...] 
> For example, 
> > different countries using the Old Style (Julian) calendar 
> started the 
> > new year on different days,[...]  The geographical area 
> identified by 
> > an ISO 3166-1 country code is defined by the present-day 
> boundaries of 
> > that country, not by the boundaries as they existed historically.
> 
> The functionality you describe in this paragraph is indeed 
> interesting, but two questions arise: 1) Who is going to 
> implement it? and 2) Doesn't the issue of the last sentence 
> destroy the whole thing?
> 
> As to the first point, do you have a particular source in 
> mind for implementing these formatting routines? To me it 
> seems like extensive research would be necessary to compile a 
> table of useful corrections from the information of the 
> country argument. If you think that this argument is 
> important you should provide a reference implementation.
> 
> As to the second point, event with the addition of the the 
> ISO 3166-3 list of old countries (which I'm not sure how 
> complete it is), is a single country designation really 
> precise enough? What about regional variance? Your aim is set 
> so high, yet I don't get a clear picture of what the goal is.
> 
> My guess is that someone really needing this functionality 
> will want to provide the textual representation of the dates 
> himself, probably in the local language of the original event.
> 
> And probably more likely is that, since I presume that noone 
> will ever implement the wanted behaviour, there will be 
> corrupted data as people enter non-proleptic dates to get the 
> right display. Show me an implementation, and I will be glad 
> to be wrong.
> 
> Yours sincerely,
> Mikael Sterner
>