RE: Wierd MSXML3 Behaviour.

Subject: RE: Wierd MSXML3 Behaviour.
From: Andrew Kimball <akimball@xxxxxxxxxxxxx>
Date: Mon, 2 Oct 2000 16:41:20 -0700

1) transformNode writes its output as a BSTR.  Since a BSTR is always
encoded as UTF-16, the xsl:output encoding is ignored, and the encoding is
forced to UTF-16.  You're seeing the "Switch from current encoding..." error
because ASP converts the BSTR into a Windows-1252 (assuming your default
codepage is Latin-1) string and sends it to the client browser.  The client
browser then invokes MSXML, which parses the Windows-1252 string as XML.
When it encounters the encoding="UTF-16" in the xmldecl, it chokes because
it did not see the Unicode BOM at the beginning of the stream, and realizes
that the encoding must be invalid.

2) Unfortunately, the transformNode output code path is currently different
from the .XML property (or Save method) code path.  This means that there
are differences in behavior.  One of these differences is that transformNode
outputs encoding="UTF-16" in the xmldecl when the output encoding must be
overriden, while the .XML property code just omits the encoding attribute
altogether.  Given the confusion that this difference is creating, I'll see
if I can change the behavior of transformNode to match the Save behavior
before we RTM.  The Save behavior at least allows the Response.Write
scenario to appear to work for many scenarios (your xsl:output encoding will
still be ignored and UTF-16 will be output, but the Response.Write call will
convert the UTF-16 to your default code page, or to another code page you
specify with Session.CodePage=####).

3) transformNodeToObject where the second parameter is the Response object
is the best way to go, since its faster and simpler than the alternatives.
Since MSXSL can write directly to the Response stream, there is no need to
override the encoding (as in #1) or to reparse the output (as in #2).

~Andy Kimball

-----Original Message-----
From: Keith [mailto:keith@xxxxxxxxxxxxx]
Sent: Monday, October 02, 2000 2:40 PM
To: xsl-list@xxxxxxxxxxxxxxxx
Subject: RE: Wierd MSXML3 Behaviour.

I've had to use encoding="windows=1252" which worked good for me

-----Original Message-----
From: owner-xsl-list@xxxxxxxxxxxxxxxx
[mailto:owner-xsl-list@xxxxxxxxxxxxxxxx]On Behalf Of lists@xxxxxxxxxx
Sent: Monday, October 02, 2000 2:44 PM
To: xsl-list@xxxxxxxxxxxxxxxx
Subject: Wierd MSXML3 Behaviour.

- July MSXML3.

- XSL Sheet as follows: i.e. identity sheet.

<?xml version="1.0" ?>
<xsl:stylesheet version="1.0"
  <xsl:output method="xml" encoding="utf-8"/>
  <xsl:template match="/ | @* | node()">
      <xsl:apply-templates select="@* | node()"/>

Different results if transformed in different ways. All in ASP. Variable
"renderedXML" was created using the line renderedXML=""

Method 1):
UTF-16 appears in the resulting XML, but the XML is not displayed in IE5,
IE5 produces the error "Switch from current encoding to specified encoding
not supported."
No matter what encoding I put in the XSL stylesheet, MSXML simply seems to
ignore it and force UTF-16.

Method 2):

"xmlDOMParam.transformNodeToObject xslDOMParam.documentElement, tempXMLDom

In this scenario, IE5 parses the XML quite merrily, but this time, the
resulting XML has no encoding whatsoever, again, MSXML 3 seems to ignore the
UTF encoding, but this way rather than force UTF-16 as in (1), it simply
doesn't put anything there.

Method 3):

"xmlDOMParam.transformNodeToObject xslDOMParam.documentElement, Response".
This works fine, the encoding does appear in the resulting XML whichever
encoding I try (I've only tried UTF-8 or UTF-16).

Has anyone else found this? It seems most bizarre and inconsistent. Has
anyone tried any of these in the September MSXML3?
Someone else must have, I'm trying something so simple.


 XSL-List info and archive:

 XSL-List info and archive:

 XSL-List info and archive:

Current Thread
  • Wierd MSXML3 Behaviour.
    • lists - Mon, 2 Oct 2000 20:43:53 +0100
      • Keith - Mon, 2 Oct 2000 16:39:36 -0500
      • <Possible follow-ups>
      • Andrew Kimball - Mon, 2 Oct 2000 16:41:20 -0700 <=