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.
The following are important notes about proper installation of the SDK for MSXML 4.0 SP2:
At the command prompt type "msiexec /qn /x" and then type the appropriate product GUID. The product GUIDs are as follows:
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.
The following are documentation updates for the Document Object Model (DOM).
The following are documentation updates for the XML DOM properties.
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.
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.
The following are documentation updates for the XML DOM methods.
This section contains updates for the following topic:
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.
The following are documentation updates for the Simple API for XML (SAX) interfaces.
This section contains updates for the following topic:
The following are documentation updates for the ISAXXMLReader interface.
This section contains updates for the following topics:
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"
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.
The xml-string property in the putProperty method does not exist and should be disregarded.
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.
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.
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.
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:
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.
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.
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 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:
The Resultant Set of Policy Wizard appears.
Tip The path in the treeview is as follows:
Console Root
[username] on [machinename] - RSoP
User Configuration
Windows Settings
Internet Explorer Maintenance
Security
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.