Conformance and Security Changes in MSXML 4.0 SP2

Summary

Important This document describes the changes that have been made in MSXML 4.0 Service Pack 2 (SP2) that break with compatibility to earlier versions of MSXML 4.0. While the list has been reviewed for technical accuracy by the Microsoft XML team, do not interpret this list as a complete or final list of changes. Potentially, additional breaking changes might exist in some usage cases. If you suspect that you have experienced a breaking change in MSXML 4.0 that is not documented in this article, contact Microsoft Product Support Services (PSS) to report the breaking change, and to receive additional technical support.

The following changes have been made in MSXML 4.0 SP2:

XSD Validation Enforces Restriction That Is Defined on a Base SimpleType
DOM: SetAttribute() Raises an Error When the Attribute Value Contains Invalid XML Characters
Importing Schemas Are Imported in Included Schemas
Is Not Permitted in an Extension When the Base Type Is Not Empty
XSD Uniqueness Identity Constraint Is Checked When Xsi:type Is Used to Change the Type of an Element
Security Is Tightened When You Post Data by Using the ServerXmlHttp Object

↑ Back to the top

More Information

XSD Validation Enforces Restriction That Is Defined on a Base SimpleType

In the original released version of MSXML 4.0 and in MSXML 4.0 Service Pack 1 (SP1), the XML schema validator does not enforce restrictions that are defined on base simpleTypes. Validating the data in the following sample XML document (Restriction.xml) against the sample schema (Restriction.xsd) does not raise any errors in the original released versions of MSMXL 4.0 and MSXML 4.0 SP1 even though the value of the AlphaTestValue element contains a character (the "-" character) that is restricted by the AlphaType base simpleType:

Restriction.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="unqualified">
 <xsd:element name="AlphaTestValue" type="AlphaTypeMaxLength6"/>
<xsd:simpleType name="AlphaType">
<xsd:restriction base="xsd:string">
<xsd:pattern value="[A-Z]*"/>   
 </xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="AlphaTypeMaxLength6">
<xsd:restriction base="AlphaType">
<xsd:maxLength value="6"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>

Restriction.xml

<?xml version="1.0"?>
<AlphaTestValue>ABCDE-</AlphaTestValue>

In MSXML 4.0 SP2, a fix has been implemented to enforce restrictions that are defined on base simpleTypes when validating XML data. This is a breaking change that has been implemented to enhance compliancy with the World Wide Web Consortium (W3C) XML Schema specification. XML data that violates restrictions that are defined on base simpleTypes fail validation in MSXML 4.0 SP2.

back to the top

DOM: SetAttribute() Raises an Error When the Attribute Value Contains Invalid XML Characters

The IXMLDOMElement.setAttribute() method has been fixed to generate an error when a specified attribute value contains invalid XML characters.

The following are the valid XML characters and character ranges (hexadecimal values) that are defined by the W3C XML language specifications 1.0:

#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] |[#x10000-#x10FFFF]

This is a breaking change that has been implemented to enhance compliancy with the W3C XML specification. You receive a runtime error message after you upgrade to MSXML 4.0 SP2 if you have code that uses the setAttribute DOM API method to assign values that contain invalid XML characters to XML attributes. To resolve this, you must change your code so that you do not use invalid XML characters in attribute values.

back to the top

Importing Schemas Are Imported in Included Schemas

In MSXML 4.0 SP2, you must explicitly import schemas that are imported in included schemas so that the including parent schema can use or can reference schema definitions that they contain. For example, this is true if the following dependencies between three separate XML schemas are in effect:

Schema A (a.xsd) uses an XSD include element to include Schema B (b.xsd). In the context of the explanation, Schema A is the including schema and Schema B is the included schema.
Schema B uses an XSD import element to import Schema C (c.xsd)

If Schema A (a.xsd) then tries to use schema components that are defined in Schema C without explicitly importing Schema C, the following error message is generated when Schema A is compiled:

'<Namespace URI>' is an invalid targetNamespace URI.

The error occurs in MSXML 4.0 SP2 because Schema A does not explicitly import Schema C. Schema A should contain an explicit import element to explicitly import Schema C by specifying the corresponding namespace and schemaLocation attributes. It is not sufficient to only specify the namespace attribute. You must also specify the schemaLocation attribute of Schema C.

This change was made in MSXML 4.0 SP2 to gain more compliancy with the W3C XML Schema specification.

back to the top

<all> Is Not Permitted in an Extension When the Base Type Is Not Empty

MSXML 4.0 SP2 prevents the use of the <all> particle in a complex type extension when the base type is not empty. When you try to use the XSD <all> particle in this context, you receive the following error message when the schema is compiled:

<all> is not the only particle in a <group> or being used as an extension

The following is a sample schema that illustrates an invalid use of the <all> particle in a complex type extension:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:complexType name="DataReader">
<xs:sequence>
<xs:element name="PacketSize" type="xs:integer"/>
<xs:element name="Encrypt" type="xs:Boolean"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="NetworkReader">
<xs:complexContent>
<xs:extension base="DataReader">
    <xs:all>
                                <xs:element name="ServerAddress" type="xs:string"/>
                                <xs:element name="ServerPort">
                                           <xs:simpleType>
                                                 <xs:restriction base="xs:integer">
                                                        <xs:minInclusive value="0"/>
                                                        <xs:maxInclusive value="65535"/>
                                                  </xs:restriction>
                                           </xs:simpleType>
                                         </xs:element>
                                <xs:element name="RecvTimeoutMS" type="xs:nonNegativeInteger" minOccurs="0"/>
    </xs:all>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>

The W3C XML Schema specification does not permit the use of the XSD all element when extending a non-empty base complexType. In this specific sample, you can use an XSD schema sequence element (<xs:sequence>) instead of using the all element (<xs:all>) to define the complex content extension. For more information about what is permitted in complexType extension rules, see the XML Schema specification.

back to the top

XSD Uniqueness Identity Constraint Is Checked When Xsi:type Is Used to Change the Type of an Element

The original release of MSXML 4.0 and MSXML 4.0 SP1 contained a bug where uniqueness identity constraints on elements were not validated when the types of the elements were changed by using the XML schema instance xsi:type attribute. This has been fixed in MSXML 4.0 SP2 so that a validation error message is generated.

For example, when you try to validate the following Products.xml document against the Products.xsd schema, you receive a validation error message that indicates that there is a duplicate Product ID in the data:

Products.xml

<?xml version="1.0"?>
<Catalog xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <products>
<product>
<productID xsi:type="ProductIdType">Prod1</productID>
        </product>
<product>
<productID xsi:type="ProductIdType">Prod1</productID>
        </product>
    </products>
</Catalog>

Products.xsd

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <xsd:element name="Catalog" type="catalogType" />
    <xsd:complexType name="catalogType">
        <xsd:choice>
            <xsd:element name="products">
                <xsd:complexType>
                    <xsd:choice maxOccurs="100">
                        <xsd:element name="product" maxOccurs="unbounded">
                            <xsd:complexType>
                              <xsd:sequence>
                                <xsd:element name="productID" type="xsd:string"/>
                              </xsd:sequence>
                            </xsd:complexType>
                        </xsd:element>
                    </xsd:choice>
                </xsd:complexType>
                <xsd:unique name="unique_part">
                    <xsd:selector xpath="./product" />
                    <xsd:field xpath="productID" />
                </xsd:unique>
            </xsd:element>
        </xsd:choice>
    </xsd:complexType>
    <xsd:simpleType name="ProductIdType">
        <xsd:restriction base="xsd:string">
            <xsd:maxLength value="5"/>        
        </xsd:restriction> 
    </xsd:simpleType>
</xsd:schema>

back to the top

Security Is Tightened When You Post Data by Using the ServerXmlHttp Object

Security in the implementation of the MSXML 4.0 SP2 ServerXmlHttp object has been enhanced to check the Internet Explorer security policy setting for submitting non-encrypted form data. When you set the
Submit nonencrypted form data security policy to
Disable or to Prompt, the following error message may be generated when you try to execute an HTTP POST by using the ServerXmlHttp object:

Access Denied

This is a change that can potentially break existing code that uses earlier versions of the ServerXmlHttp object (MSXML 3.0 and its current service packs, the original release of MSXML 4.0, and MSXML 4.0 SP1) to execute an HTTP POST when the Internet Explorer security policy setting for submitting non-encrypted form data is not enabled.

To configure Internet Explorer security to allow the submitting of nonencrypted form data for all users on a computer, do the following in Microsoft Windows 2000 and later:

Click Start, click Run, type mmc, and then press ENTER.
On the File or the Actionmenu, click Add/Remove Snap-in.
In the Add/Remove Snap-in dialog box, click Add.
On the Standalone tab, click
Add. In the Available Standalone Snap-indialog box, click Group Policy , and then click
Add. The Group Policy Wizard appears.
In the Group Policy Wizard, Click
Finish
Close the Add Standalone Snap-in window by clicking the Close button
Click OK in the Add/Remove Snap-in dialog box.
Under User Configuration, expand
Windows Settings, expand Internet Explorer Maintenance, and then click Security.
In the right pane, double-click Security Zones and Content Ratings.
Under Security Zones and Privacy, click
Import the current security zones and privacy settings, and then click Modify Settings.
Select the zone that you would like to modify, and click
Custom Level
Modify the settings to enable the Submit nonencrypted form data option by selecting the enableradio button for that option. If it is already enabled, then just click the
OK button.

The zone where the setting should be enabled is determined by the zone where the target URL of the POST operation is classified. For example, when you post to an Internet URL, you must enable this option for the internet zone.
Restart the process that is running ServerXMLHTTP. To do this, you may have to restart your computer.

On a computer that is running Windows Server 2003 in Internet Information Services (IIS) 6.0 mode, changing this setting has no affect and you continue to receive the following error message:

Access Denied

This is caused by an additional security feature that is named “Enhanced Internet Explorer Settings”. On some computers, this is installed by default. On other computers, you can add it through Windows Components by using the Add/Remove Programs tool in Control Panel.

If an additional security lock down on the account that runs the IIS6 process is in effect, use one of the following methods to work around the problem:

Method 1: Run the specified Web sites, or virtual directories in a separate IIS pool ,and then create a user that the pool will run under.
Method 2: Create a new DLL, write code to do ServerXMLHTTP calls, and then host the DLL in COM+ under a new user.
Method 3: Use WinHTTP by changing the Prog ID from
MSXML2.ServerXMLHTTP.4.0 to WinHTTP.WinHTTPRequest.5.1.

back to the top

↑ Back to the top