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:
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
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
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:
- From the Start menu, click Run, type "mmc" and then press
ENTER.
- From the File menu, select Add/Remove Snap-In.
- In Add/Remove Snap-In, click Add.
- 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.
- Complete the Resultant Set of Policy Wizard using the following settings:
- For Mode Selection, select Logging mode
- For Compute Selection, select this computer.
- For User Selection, select Display policy settings for and
Current user.
- 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
- In the details pane, select Security Zones and Content Ratings.
- From the Action menu, select Properties.
- In Security Zones and Content Ratings, select Import the current
security zones and privacy settings.
- Click View Settings.
- 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.
