# MSXML 4.0 SP2 Release Notes

The following release notes contain documentation updates to the Microsoft® XML Core Services (MSXML) 4.0 Service Pack 2 (SP2) Software Development Kit (SDK). Use the headings below to locate the updated topic in the MSXML 4.0 SP2 SDK table of contents.

> Note These release notes update but do not replace the documentation found in the SDK.

## Upgrading to the MSXML 4.0 SP2 SDK

The following are important notes about proper installation of the SDK for MSXML 4.0 SP2:

- The MSXML 4.0 SP2 SDK is not installed or upgraded by default.
- To properly install or upgrade to the MSXML 4.0 SP2 SDK, uninstall the previous version of MSXML 4.0 and then install MSXML 4.0 SP2 with the custom option to install the SDK selected.
- If you do not uninstall previous versions of the MSXML4.0 SDK, the existing SDK shortcut on the desktop and start menu will refer to the previous version of the SDK.
- The file names of the MSXML 4.0 SP2 SDK have been changed to xmlsdk4.chm and xmlsdk4.chi.
- To uninstall previous versions of MSXML 4.0 quietly, use the command line option (this option will remove the desktop icon and SDK files):

  At the command prompt type "msiexec /qn /x" and then type the appropriate product GUID. The product GUIDs are as follows:

  - MSXML 4.0 SP1 GUID = {35343FF7-939B-401A-87B3-FF90A5123D88}
  - MSXML 4.0 GUID = {2AEBE10C-D819-4EBF-BC60-03BF2327D340}

## Redistributing MSXML

The MSXML 4.0 merge module redistribution package allows you to distribute MSXML 4.0 with any Microsoft Windows® desktop application you build using Microsoft Visual Basic® 6.0 or Visual C++® 6.0.

The following updates the "To create a Windows Installer package that installs MSXML 4.0 with your application" procedure.

You are now required to include two merge modules, msxml4sys32.msm (installs DLL files in the \Windows\system32\ directory on all supported versions of Windows), and msxml4sxs32.msm (installs DLL files in the \Windows\WinSxS directory on Windows XP or later versions of Windows). When following this procedure, replace the msxml.msm merge module listed in the procedure with msxml4sys32.msm and msxml4sxs32.msm.

## DOM Reference

The following are documentation updates for the Document Object Model (DOM).

### XML DOM Properties

The following are documentation updates for the XML DOM properties.

- dataType Property
- nodeTypedValue Property

#### dataType Property

The following statement in the remarks section for the `dataType` property is incorrect.

"This property applies to DTDs only, not to XML-Data Reduced (XDR) schemas or XML Schemas (XSD)."

The following updates the remarks section for the `dataType` property.

This property applies to Document Type Definition (DTD) and XDR schemas and it does not apply to XML Schemas (XSD).

When an XML document is defined by an XSD schema, the `dataType` property for all nodes will have the value of `VT_NULL`. The `dataType` property is for XDR or DTD schemas. If you have an XSD schema, you find the type of a node by calling `getDeclaration` and then getting the `itemType`. The `dataType` of elements defined in XSD schemas are not initialized and will return `VT_NULL`. In addition, the `nodeTypedValue` property depends on the `dataType` to return the value information. If the `dataType` property is missing, it will return the variant as a `VT_BSTR` type.

The reason for this behavior is that XSD schemas can define complicated custom types and there is no implementation in MSXML 4.0 to directly map between XSD types and COM variant types.

#### nodeTypedValue Property

The following updates the remarks section for the `nodeTypedValue` property.

This property applies to Document Type Definition (DTD) and XML-Data Reduced (XDR) schemas and it does not apply to XML Schemas (XSD).

When an XML document is defined by an XSD schema, the variant returned by calling the `nodeTypedValue` property is always of type `VT_BSTR`. The `dataType` property is for XDR or DTD schemas. If you have an XSD schema, you find the type of a node by calling `getDeclaration` and then getting the `itemType`. The `dataType` of elements defined in XSD schemas are not initialized and will return `VT_NULL`. In addition, the `nodeTypedValue` property depends on the `dataType` to return the value information. If the `dataType` property is missing, it will return the variant as a `VT_BSTR` type.

The reason for this behavior is that XSD schemas can define complicated custom types and there is no implementation in MSXML 4.0 to directly map between XSD types and COM variant types.

You can explicitly set the `nodeTypedValue` property with a particular data type in the variant. The set operation does not change the data type. The value in the variant is converted to the data type specified in the `dataType` property, and the set operation returns an error if the type conversion is not possible.

When working with an XSD schema, you can get the corresponding variant type by setting the `dataType` property before calling the `nodeTypedValue` property. A data conversion will occur, but it may not always be possible. If the data conversion is not possible, a COM exception will be thrown.

### XML DOM Methods

The following are documentation updates for the XML DOM methods.

This section contains updates for the following topic:

- setOption Method

#### setOption Method

The following updates the remarks section for the `SXH_OPTION_SELECT_CLIENT_SSL_CERT` option.

With MSXML 4.0, the client certificate can be installed in the local machine certificate store, whereas in the previous release the certificate was installed in the user's personal store. After the certificate has been installed, you can use the Certificates MMC snap-in to view the certificate. If you have multiple certificates installed, you can use the `setOption` method to specify the name of the certificate with a full path to the certificate.

    const SXH_OPTION_SELECT_CLIENT_SSL_CERT = 3
    http.setOption SXH_OPTION_SELECT_CLIENT_SSL_CERT, "LOCAL_MACHINE\My\my certificate"

The path specified refers to the registry key: `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\My\Certificates`.

## SAX2 Reference

The following are documentation updates for the Simple API for XML (SAX) interfaces.

This section contains updates for the following topic:

- ISAXXMLReader Interface

### ISAXXMLReader Interface

The following are documentation updates for the ISAXXMLReader interface.

This section contains updates for the following topics:

- getFeature Method
- putFeature Method
- putProperty Method

#### getFeature Method

Returns the Boolean value of a feature.

In addition to the features listed in the MSXML 4.0 SP2 SDK, the following feature is also supported:

    "use-schema-location"

#### putFeature Method

Sets the value of a feature.

In addition to the features listed in the MSXML 4.0 SP2 SDK, the `ISAXXMLReader` interface recognizes the following feature:

    "use-schema-location"

True — (default) Use `xsi:schemaLocation` to load external schemas.

False — External schemas will not be loaded.

Access — (parsing) read-only; (not parsing) read/write.

#### putProperty Method

The `xml-string` property in the `putProperty` method does not exist and should be disregarded.

## List Of Known Breaking Changes In MSXML 4.0 SP2

> Disclaimer This following section of this document describes changes made in MSXML 4.0 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, it should not be interpreted as a complete or final list of any such changes. Potentially, additional breaking changes might exist in some usage cases. If you suspect you have come across a breaking change in MSXML 4.0 not documented here, please contact Microsoft Product Support Services (PSS) to report it and receive further technical support.

### XSD validation will enforce <xsd:restriction> on a base <xsd:simpleType> rule

In MSXML 4.0 RTM and SP1, XML schema validation does not enforce restrictions that are defined on base simpleTypes.

For example, in either of these prior versions of MSXML 4.0, no validation errors occur if you validate the data in the following sample XML document (Restriction.xml) against the sample schema (Restriction.xsd).

Restriction.xml

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

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>

In these earlier versions of MSXML 4.0, no validation error would be reported even though the value of the `<AlphaTestValue/>` element contains a character (the "-" character) restricted by the schema, as indicated by the base type restriction in the `<xsd:simpleType name="AlphaType"/>` schema rule (highlighted above).

In MSXML 4.0 SP2, however, any XML data that violates restrictions defined on base simpleTypes fail validation. For example, MSXML 4.0 SP2 will raise a validation error when validating Restriction.xml against the Restriction.xsd schema. This breaking change was implemented to enhance compliancy with the World Wide Web Consortium (W3C) XML Schema specification.

### SetAttribute Method Raises Error When Attribute Value Contains Invalid XML Characters

In MSXML 4.0 RTM and SP1, the IXMLDOMElement.setAttribute() method would not report errors if the attribute value specified with this method contained invalid XML characters.

For MSXML 4.0 SP2, only valid XML characters and character ranges are allowed for use with the setAttribute method. Valid ranges for XML character data are defined by the W3C XML language specifications 1.0 as characters within the following ranges of hexadecimal values:

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

If you upgrade to MSXML 4.0 SP2 and then attempt to use setAttribute to set attribute values that contain invalid XML characters, you will receive a runtime error message.

This is a breaking change that has been implemented to enhance compliancy with the W3C XML specification. To resolve this, you must change your code so that you do not permit the use of invalid XML characters when setting attribute values.

### Schemas imported in included schemas must be explicitly imported in including parent schema

In MSXML 4.0 SP2, you must explicitly import schemas that are imported in included schemas so that the including parent schema can use/reference schema definitions that they contain.

For example, if the following dependencies between three separate XML schemas is in effect:

- Schema A (a.xsd) uses an XSD include element to include schema B (b.xsd)
- Schema B uses an XSD import element to import Schema C (c.xsd)

If Schema A (a.xsd) then attempts to use schema components defined in Schema C, the following error message might be generated when Schema A is compiled:

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

To resolve this error, Schema A needs to contain an XSD import element with corresponding namespace and schemaLocation attributes that explicitly import Schema C. Both attributes are required. An import element with just the namespace attribute alone will not suffice. The schemaLocation must also be included and it must specify the location of Schema C.

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

### <xsd:all> not permitted in an <xsd:extension> when base type is not empty

MSXML 4.0 SP2 prohibits the use of the XSD all element in a complex type extension when the base type is not empty. This change was made in MSXML 4.0 SP2 to achieve further compliancy with the W3C XML Schema specification. Any attempt to use the XSD all element in this context will result in the following error 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 features an invalid use of XSD all element in a complexContent 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 for instance, an XSD schema sequence element could be used instead of the all element to define the complex content extension. For more information on what is permitted in complexType extension rules, refer directly to the XML Schema specification.

### XSD uniqueness identity constraints now checked when using XSI type attribute

In MSXML 4.0 RTM and SP1, if an element's type was changed using the XML schema instance xsi:type attribute, any uniqueness identity contraints on those elements were not performed as part of validation. This was a bug that has been fixed in MSXML 4.0 SP2.

For instance, in MSXML 4.0 SP2 an attempt to validate the following Products.xml document against the Products.xsd schema will generate a validation error message reflecting the presence of 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>

### Security tightened when posting data 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. A security policy setting of "Disable" or "Prompt" for the "Submit nonencrypted form data" option will result in an "Access Denied" error message when attempting to post form data using the ServerXmlHttp object. This is a change that can potentially break existing code that uses earlier versions of the ServerXmlHttp object (such as prior released versions of both MSXML 3.0 and MSXML 4.0) to post form data when the Internet Explorer security policy setting for submitting non-encrypted form data is not enabled.

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

1. From the Start menu, click Run, type "mmc" and then press ENTER.
2. From the File menu, select Add/Remove Snap-In.
3. In Add/Remove Snap-In, click Add.
4. In Add Standalone Snap-In, from the list of available snap-ins, scroll to Resultant Set of Policy and select it, and then click Add.

   The Resultant Set of Policy Wizard appears.

5. Complete the Resultant Set of Policy Wizard using the following settings:
   1. For Mode Selection, select Logging mode
   2. For Compute Selection, select this computer.
   3. For User Selection, select Display policy settings for and Current user.
6. In the Resultant Set of Policy snap-in, expand the treeview in the action pane and browse to Security.

   > Tip The path in the treeview is as follows:

       Console Root
          [username] on [machinename] - RSoP
             User Configuration
                Windows Settings
                   Internet Explorer Maintenance
                      Security

7. In the details pane, select Security Zones and Content Ratings.
8. From the Action menu, select Properties.
9. In Security Zones and Content Ratings, select Import the current security zones and privacy settings.
10. Click View Settings.
11. In View Settings, modify the settings to enable the "Submit nonencrypted form data" option for the appropriate zone.

    The zone for which the setting should be enabled is determined by the zone under which the target URL of the POST operation is classified. For instance, when posting to an Internet URL you will need to enable this option for the Internet zone.