FW: [XSLT 2.0] format-dateTime localised picture parameters

Richard Zschech sent the following response to my personal email
address; I am forwarding it to the list for the archives. - MK

-----Original Message-----
From: Richard Zschech [mailto:richard.zschech@cqrdata.com] 
Sent: 26 January 2004 11:54
To: Kay, Michael
Subject: Re: [XSLT 2.0] format-dateTime localised picture parameters


Sorry about the resend. Here is is without the formatting |s

Kay, Michael wrote:

> Richard Zschech raised this comment {qt-2003Nov0055-01}:
>
> http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Jan/0031.html
>
> The Working Group considered this proposal on 2004-01-20 and decided 
> not to add the new functionality requested.
>
> There were a number of reasons:
>
> (a) It would be difficult to make any kind of definitive statement of 
> what "short", "medium", and "long" were supposed to mean, other than 
> by example
>
>  
>

I would define the meaning of "short", "medium", and "long" as follows 
based on section 16.5.2 (The language, calendar, and country arguments):

The "short", "medium", and "long" picture strings are used as aliases to

language and country dependent picture strings.

The language is used to select the appropriate language-dependent forms 
of the "short", "medium", and "long" picture strings. The function being

called should also be used to determine the type defendant form, for 
example "format-dateTime", "format-date", and "format-time" should 
produce date/time, date, and time picture strings. Where appropriate 
this choice may also take into account the value of the country 
argument, though this should not be used to override the language or any

sublanguage that is specified as part of the language argument.

The choice of the aliased picture strings for any given language is 
implementation-defined. For example, one implementation might alias  
"short" as "[M]-[D]-[Y]" while another uses "[M01]-[D01]-[Y0001]". 
Implementations may provide mechanisms allowing users to control such 
choices.



Given that other date formatting is implementation dependent, I don't 
think that this is an issue. For example, with month abbreviations, one 
implementation might abbreviate July as Jul while another uses Jly. In 
German, one implementation might represent Saturday as Samstag while 
another uses Sonnabend.

> (b) We don't currently have any functionality that depends explicitly 
> on the user's locale or localization preferences, and it would be 
> difficult to define this concept
>  
>

Maybe locale was the wrong word to use - language and country are 
sufficient.

> (c) We felt the required functionality could easily be provided by a 
> function library sitting on top of the current date/time formatting 
> functionality that is already provided: in other words, it was 
> non-core.
>  
>

Providing the functionality in a library would be possible but 
inelegant. The library writer would have to create a table of picture 
strings for all the combinations of language, country and picture alias.

Also, doing the formatting would require calling the library like so, 
format-time($t, picture("short", "en", "gb"), "en", (), "gb"), which is 
a bit messy.

The XSLT Requirements section 2.2 (Must Add Date Formatting Functions) 
says:" Functionality similar to that provided by 
java.text.SimpleDateFormat." which includes support for language and 
country "short", "medium", and "long" formatting.  The use case refers 
to formatting "according to the current locale" as well. If this is a 
"must" requirement then it should be core functionality and not provided

by a library.

> Richard: thank you for raising the comment. I would be grateful if you

> could confirm that this response is acceptable.
>
> Regards,
>
> Michael Kay
>  
>
I respectively ask the working group to reconsider this issue based on 
my arguments.

Thanks, from Richard.

Received on Monday, 26 January 2004 10:32:27 UTC