W3C home > Mailing lists > Public > public-qt-comments@w3.org > June 2004

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

From: Michael Kay <mhk@mhk.me.uk>
Date: Wed, 30 Jun 2004 11:25:37 +0100
To: <public-qt-comments@w3.org>
Cc: "'Richard Zschech'" <richard.zschech@cqrdata.com>
Message-Id: <20040630102615.42A15A09CF@frink.w3.org>

Forwarded to the list for archiving purposes.

-----Original Message-----
From: Richard Zschech [mailto:richard.zschech@cqrdata.com] 
Sent: 30 June 2004 10:48
To: Michael Kay
Subject: Re: [XSLT 2.0] format-dateTime localised picture parameters long
medium short

I'm sorry but this idea seems like a bit of a kluge. The system-property 
function would
be the last place that I would look for something like this.

Again it is not very elegant, for example:

    format-time($t, system-property("xsl:short-time-format"), "en", (), 

is not as simple as:

    format-time($t, "short", "en", (), "gb")

This scheme does not give the style sheet control over the language and 
country of the
format. For example the following would not reorder the day and month 
for the "gb"
and "us" countries:

    format-date($t, system-property("xsl:short-date-format"), "en", (), 
    format-date($t, system-property("xsl:short-date-format"), "en", (), 

This also allows for nonsensical cases by mixing up types which will 
cause a recoverable
dynamic error for example:

    format-date($t, system-property("xsl:short-time-format"))
    format-time($t, system-property("xsl:short-date-format"))

this would not be possible if the strings "short", "medium", "long" and 
"full" were used.

I suspect these system properties will not be well supported because it 
depends on
implementations creating a table for all combinations of language, 
country and 12
properties. For example

    en, gb, short-date-format -> "[M]-[D]-[Y]"
    en, us, short-date-format -> "[D]-[M]-[Y]"

Allowing the implementation to recognise the string "short" for example
and then using:

    DateFormat.getDateInstance(DateFormat.SHORT, new Locale(language, 

or other platform specific methods, would be much simpler for implementors.

Also I would expect implementers of format-dateTime to take advantage of 
their platform
specific date formatting to do all the language conversions. They would 
do this by  converting the XSL pattern to to their platform specific
pattern. Then they would call their platform specific date formatter to 
do all the
language conversions. For example, using SimpleDateFormat in Java, 
convert "[MNn]"
to "MMMM".

Again can you please reconsider this issue based on my arguments.

 From Richard.

Michael Kay wrote:

>Our ref: issue qt-2003Nov0055-01
>Following your request for us to re-examine our previous decision on this
>comment, we took another look at it yesterday and decided to add some
>functionality which we hope will meet the requirement.
>The new functionality takes the form of a set of system properties,
>accessible through the system-property function, with names such as
>xsl:short-date-format, xsl:long-dateTime-format, and so on. There will be
>of these properties: (short, medium, long, and full) for each of (date,
>time, dateTime). The value of the property will be a picture string that
>be used as the second argument to the format-date/time() function. The
>precise form of the output will not be defined, there will merely be a
>general statement of the intent, and some examples to guide implementors
>users in what to expect. These examples will be based on the usage in Java.
>Could you please confirm that this new facility meets the requirement you
>Michael Kay
>for the XSL Working Group 
Received on Wednesday, 30 June 2004 06:26:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:20 UTC