Question regarding different behaviour between using command line invocation and standard call

[Claus Kick <cl...@googlemail.com>]

Hello list,

I have been using Xalan for many, many tasks in many different projects and
at many different opportunities.
This is a really great tool which makes working with huge amounts of data so
much easier.

I have a question however; most of the times, I have been using perl code to
generate command line calls for xalan

i.e. something like the following:

set XMS=-Xms256m
set XMX=-Xmx384m

d:
cd D:\xslt\xalan
java %XMS% %XMX%  -classpath
xalan.jar;serializer.jar;xml-apis.jar;xercesImpl.jar
org.apache.xalan.xslt.Process  -in D:\exports\tmpexport19\tmpexport19 -xsl
D:\xslt\transformation.xsl  -out
D:\\exports\ENS_translation_information021309_032038.xml -param
targetLanguage ENS -param sourceLanguage DEU

java %XMS% %XMX% -classpath
xalan.jar;serializer.jar;xml-apis.jar;xercesImpl.jar
org.apache.xalan.xslt.Process  -in D:\exports\tmpexport19\tmpexport19 -xsl
D:\xslt\transformation2.xsl  -out
D:\exports\ENS_translation_started021309_032038.xml -param targetLanguage
ENS


Now, I have a small SWT GUI project which allows setting a couple of
switches and then calls Xalan to do certain transformations with certain
attributes and so on.

What I am using in my Java project is the following (Exception handling
removed for increased readability):

    public  void runXalan1(String targetLanguage, String sourceLanguage)
    {
        Source xmlSource = null;
        xmlSource = new StreamSource(new File(MainWindow.getSourceFile()));
        Source xslSource = null;
        xslSource = new
StreamSource(this.getClass().getResource("/xslt/transformation.xsl").openStream());

        Transformer transformer = null;
        transformer = tFactory.newTransformer(xslSource);

        File outfile = new File(MainWindow.getExportDirectory() +
File.separator    + "test" + "_" +  GUIHelper.getTimestamp() + "_" +
targetLanguage + ".xml");
        outfile.createNewFile();

        transformer.setParameter("targetLanguage", targetLanguage);
        transformer.setParameter("sourceLanguage", sourceLanguage);

        transformer.transform(xmlSource, new StreamResult(outfile));
     }


The problem now is that the XML files I receive use the following encoding:

<?xml version="1.0" encoding="Cp1252"?>

The command line calls never complained about this, calling the transformer
directly yields

file:///C:/temp/tmpexport4/tmpexport4; Line #1; Column #40; Invalid encoding
name "Cp1252".

And my result XML file is empty.

Normally, I cannot change the XML I receive.
If, for testing purposes I change CP1252 to "windows-1252", the transformer
does not complain.
What have I overlooked in configuring the transformer?

Could someone please shed some light on this and show me my mistake?

Cheers,

Claus

Re: Question regarding different behaviour between using command line invocation and standard call

[Michael Ludwig <mi...@gmx.de>]

Claus Kick schrieb am 06.04.2009 um 16:00:28 (+0200):
> 
> <?xml version="1.0" encoding="Cp1252"?>

That's invalid. The encoding has to be specified using the official,
cross-platform IANA names. See:

  http://www.w3.org/TR/REC-xml/#IANA
  http://www.iana.org/assignments/character-sets

> The command line calls never complained about this

Mine do.

> calling the transformer directly yields
> 
> file:///C:/temp/tmpexport4/tmpexport4; Line #1; Column #40; Invalid
> encoding name "Cp1252".

That's what you should get.

> And my result XML file is empty.

The data can't be parsed, because it's not valid XML, so there is no
input tree for the transformer, and the transformation isn't started.

> Normally, I cannot change the XML I receive.

Your data is not valid XML. So there's arguably some reason for an
exception here ...

> If, for testing purposes I change CP1252 to "windows-1252", the
> transformer does not complain.

And it shouldn't, because that's the correct name.

> What have I overlooked in configuring the transformer?

I haven't checked, but the problem here is your data provider.

Best,

Michael Ludwig