Hi Jirka, I investigated the problem a little bit. When the Java VM is started it takes the default locale from the platform. In your case I suspect this is Czech. But when you use Oxygen, Oxygen does not have support in the GUI for Czech so you probably use it in English. Depending on the language the user has chosen, Oxygen will also set this language as the default locale. So when running from Oxygen with English-translated labels, the default locale for the Java VM is English. Now for the command line execution: From what I've tested, regardless of the value which you set in the @sort attribute, the behavior is the same. So if I have something like:
<xsl:sort select="." lang="en"/>
in the XSL the following command line will properly sort according to the Czech rules:
java -Duser.language=cs -Duser.country=CZ -jar lib/saxon9ee.jar -it:main -xsl:D:/projects/eXml/samples/test.xsl
and if I run:
java -Duser.language=en -Duser.country=EN -jar lib/saxon9ee.jar -it:main -xsl:D:/projects/eXml/samples/test.xsl
the nodes are sorted according to English rules. Do you obtain the same behavior on your side? I looked in the Saxon code and regardless of the @sort attribute value the method:
net.sf.saxon.java.JavaCollationFactory.makeCollation(Configuration, String, Properties)
does not receive any value for the "lang" key property and thus the code falls back to:
collator = Collator.getInstance(); // use default locale
which is "English" when running in Oxygen or Czech when running the command line. So I think this is a bug in Saxon because the code which deals with the language from "net.sf.saxon.expr.sort.SortKeyDefinition" avoids setting any property value if the language expression is a string literal (which it always is):
if(languageX.length() != 0 && !(language instanceof StringLiteral)) { net.sf.saxon.lib.ConversionRules rules = config.getConversionRules(); net.sf.saxon.type.ValidationFailure vf = StringConverter.STRING_TO_LANGUAGE.validate(languageX); if(vf != null) throw new XPathException("The lang attribute of xsl:sort must be a valid language code", "XTDE0030"); props.setProperty("lang", languageX); }
Regards, Radu Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 7/24/2012 8:23 PM, Jirka Kosek wrote:
On 24.7.2012 16:44, George Cristian Bina wrote:
I get the same results both from command line and from oXygen. We tested this on Mac, Windows and Linux. Can you try without the lang attribute from the command line - I suspect you will get the same result as with lang="cs" on that machine.
Hi George, output without lang="cs" is different on command-line and same in oXygen. I even used used oXygen local JRE and saxon9ee.jar bundled with oXygen to test it. And there is still difference.
Anyway, we will investigate more on what is happening and come back with more details as soon as we have them.
I don't know whether this could be related, but I recently installed 64-bit version of oXygen 14.
Thanks for investigation,
Jirka
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user