Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: [xsl] Different results of format-date() when using empty seq. or omitting args for lang/cal/country args

From: "Michael Kay" <mike@------------>
To:
Date: 10/2/2006 2:05:00 PM
> While trying to output a value as ISO calendar using a 
> default language, I came across a little niche in the xslt 
> specification that I find hard to interpret right. My problem 
> is this: when I want to output as ISO calendar, I have to 
> provide the last three arguments for format-date(). 
> The spec says that I can use the empty sequence to use for 
> the default value, which value is implementation-defined. 
> Fair enough. But when I use the empty sequence for language, 
> the processor defaults to language X and outputs with 
> [Language: en] somedate, saying in fact that it does not 
> support the default language requested! Am I missing 
> something, or is this is a processor dependent bug?

Saxon is taking the default from the Java locale, and then falling back to
English if you haven't installed a date localisation for that locale. It
would probably be more sensible to collapse these two steps, which would
mean you didn't get the [Language: en] in the output.

The current behaviour of Saxon is conformant with the spec, but there are
other conformant behaviours that might be more user-friendly.

Michael Kay
http://www.saxonica.com/

> 
> My hunch is that the processor takes the current language 
> setting from system properties, which is, likely, to vary 
> from system to system (in my case 'nl'). What I expected it 
> to, is to default to a fixed language code, namely 'en' (or 
> any other for that matter). That way, the following two 
> statements would be equal:
> 
> Ex 1) format-date(current-date(), '[D1]/[Y1]') Ex 2) 
> format-date(current-date(), '[D1]/[Y1]', (), (), ())
> 
> Output ex. 1) 10/2006
> Output ex. 2) [Language: en] 10/2006
> 
> In some way, this feels like violating the specs, but I 
> cannot be sure of that. The specs say: "When any of these 
> arguments is omitted or is an empty sequence, an 
> implementation-defined default value is used."
> 
> You can only omit all three last arguments at once. I expect 
> the "default value" to be the same all the time, instead 
> being different for 'omitting' and 'empty sequence'.
> 
> I would like to use the following statement (3), for logging 
> my stuff to some system. Unfortunately I have to resort 
> statement (4), to get rid of the [Language: en] part in the 
> output. But specifying the language does not feel right, 
> because I want the default to be used, to be sure the 
> processor can support the default (but it doesn't).
> 
> Ex 3) format-date(current-date(), '[D1] [MNn] [Y1], (), 
> 'ISO', ()) Ex 4) format-date(current-date(), '[D1] [MNn] 
> [Y1], 'en', 'ISO', ())
> 
> Output ex 3) [Language: en]2 October 2006 Output ex 4) 2 October 2006
> 
> Does anybody has some experience with this with other processors? 
> Anybody any thoughts on this or on how I should interpret the 
> particular part of the specs? Is the spec indeed open to 
> implement for different outputs for (1) and (2), or is that 
> an error in the processor?
> 
> I tested with Saxon 8.7.1
> 
> Cheers,
> Abel Braaksma


transparent
Print
Mail
Digg
delicious
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent