INFO: List of Issues Fixed in MSXML 4.0 SP2 (Part 2 of 4)

This article has been archived. It is offered "as is" and will no longer be updated.

Fix: Xsl:sort Does Not Sort the Data Correctly When You Cross-Reference Two Documents in the Sort

In MSXML 4.0 RTM and SP1, xsl:sort does not sort the data correctly when you cross-reference between two documents in the sort.

To reproduce the problem, use the following .xml and .xsl files:

Test.xml
<large-collection> <collection name = "groupA"> <ref refid="1"/> <ref refid="3"/> </collection> <collection name = "groupB"> <ref refid="3"/> <ref refid="4"/> </collection> <collection name = "groupC"> <ref refid="1"/> <ref refid="2"/> <ref refid="3"/> <ref refid="4"/> <ref refid="5"/> <ref refid="6"/> <ref refid="7"/> <ref refid="8"/> <ref refid="9"/> </collection> </large-collection>
Parts.xml
<parts> <part id="1" type="type-a" name="name-a"/> <part id="2" type="type-a" name="name-b"/> <part id="3" type="type-b" name="name-c"/> <part id="4" type="type-d" name="name-d"/> <part id="5" type="type-b" name="name-e"/> <part id="6" type="type-c" name="name-f"/> <part id="7" type="type-d" name="name-g"/> <part id="8" type="type-b" name="name-h"/> <part id="9" type="type-c" name="name-i"/> </parts>
Test.xsl
<?xml version="1.0"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:output method="html" /> <xsl:variable name="MyGroup">groupC</xsl:variable> <xsl:variable name="MyParts" select="document('parts.xml')/parts"/> <xsl:template match="/large-collection"> <xsl:apply-templates select="collection[@name = $MyGroup]" /> </xsl:template> <xsl:template match="/large-collection/collection"> <xsl:for-each select="ref">  <xsl:sort select="$MyParts/part[@id = (current())/@refid]/@type"  order="ascending"/>  <xsl:sort select="$MyParts/part[@id = (current())/@refid]/@id"  order="ascending"/>  type: <xsl:value-of select="concat($MyParts/part[@id = (current())/@refid]/@type, ' name: ', $MyParts/part[@id =  (current())/@refid]/@name, ' id: ', $MyParts/part[@id = (current())/@refid]/@id)"/>  </xsl:for-each> </xsl:template> </xsl:stylesheet>

Fix: XSD Schemas: You Cannot Use an XSD Union in the Definition of Another SimpleType

In MSXML 4.0 RTM and SP1, you cannot use an XSD union in the definition of another SimpleType. When you try to compile an XSD schema where an XSD union is used in the definition of another SimpleType, you receive the following error message:
Error number : -2147467259
Error Message : file:///C:/union.xsd#/schema[1]/simpleType[position() = 2 and @name = 'myunion2']/union[1] Union datatype must be derived from an atomic or list datatype.
This is a valid operation according to the following statement in section 4.1.2.3 of the XSD Datatypes Specifications:
{member type definitions} The sequence of Simple Type Definition components resolved to by the items in the actual value of the memberTypes [attribute], if any, in order, followed by the Simple Type Definition components resolved to by the <simpleType> [children], if any, in order. If {variety} is union for any Simple Type Definition components resolved to above, then the that Simple Type Definition is replaced by its {member type definitions}.


To reproduce the problem, use the following XML schema:
<schema targetNamespace="urn:test" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:test="urn:test" elementFormDefault="qualified" attributeFormDefault="unqualified">  <element name="info2" type="test:myunion2" />  <!--Definition of myunion datatype-->  <simpleType name="myunion"> <union> <simpleType>  <restriction base="decimal" />   </simpleType>  </union>  </simpleType> <!--  Definition of myunion2 datatype    -->  <simpleType name="myunion2"> <union> <simpleType> <restriction base="NMTOKEN">  <enumeration value="a" />   <enumeration value="b" />   </restriction>  </simpleType> <simpleType>  <restriction base="test:myunion" />   </simpleType>  </union>  </simpleType>  </schema>

Fix: Restriction of Abstract Classes with Abstract Particles Through Substitution Group Does Not Work

In MSXML 4.0 RTM and SP1, if an abstract complex type is defined with a particle that references an abstract globally declared element, and then restricts it by creating a complex type with a particle that is in the same substitution group as the abstract element in the base type, you receive the following error message:
Error Number: -2147467259
Error Message: file:///C:/schema.xsd#/schema[1]/complexType[position() = 2 and @name = 'ContainMember2Type'] Invalid particle derivation by restriction. Base type : '{urn:my-namespace}ContainHead2Type' Derived type : '{urn:my-namespace}ContainMember2Type'
To reproduce the problem, use the following XSD schema:
<?xml version="1.0" encoding="UTF-8"?><schema targetNamespace="urn:my-namespace" xmlns:my="urn:my-namespace"xmlns="http://www.w3.org/2001/XMLSchema"> <element name="Head2" type="string" abstract="true"/><element name="Member2" type="string" substitutionGroup="my:Head2"/><complexType name="ContainHead2Type" abstract="true"><sequence><element ref="my:Head2"/></sequence></complexType><complexType name="ContainMember2Type"><complexContent><restriction base="my:ContainHead2Type"><sequence><element ref="my:Member2"/></sequence></restriction></complexContent></complexType></schema>

Fix: Access Violation Occurs When You Use an XSLT Variable to Supply the Value for the Format Parameter of Format-number()

In MSXML 4.0 RTM and SP1, when you call an XSLT format-number function that has a variable as the third parameter instead of a hard-coded value, an access violation occurs. This behavior occurs only when you call the format-number function more than one time.

Example:
<xsl:value-of select="format-number($number, '#,###.00', $numberfmt)"/> <xsl:value-of select="format-number($number, '#,###.00', $numberfmt)"/>
To reproduce the problem, use the following XSL:
<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0"xmlns:xsl="http://www.w3.org/1999/XSL/Transform"><xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/><xsl:decimal-format name="locale" decimal-separator="."grouping-separator="," NaN="0.00" /><xsl:variable name="numberfmt" select="'locale'"/><xsl:variable name="number" select="324123.12"/><xsl:template match="/"><xsl:value-of select="format-number($number, '#,###.00',$numberfmt)"/><br/><!-- if the following line is ommitted, no error will occur --><xsl:value-of select="format-number($number, '#,###.00',$numberfmt)"/><br/></xsl:template></xsl:stylesheet>

Fix: Program Stops Responding When You Call the Validate() Method on an XML Document with Invalid Attribute Default ID Declaration

In MSXML 4.0 RTM and SP1, when you call the Validate() method on an XML document that has an invalid attribute default ID declaration, and the document is loaded with the validateOnParse property set to false, the program stops responding when you call the Validate() method.

To reproduce the problem, use the following XML and vbscript code:

Test.xml
<!DOCTYPE root [    <!ATTLIST root	id2 ID "x23"	>]><!-- an ID attribute must have a declared default    of #IMPLIED or #REQUIRED--><root />
Test.vbs

Fix: Attribute Order Changes When You Use the SetAttribute Method to Change an Existing Attribute Value

In MSXML 4.0 RTM and SP1, using the setAttribute(name, value) method of the DOMDocument object, changes the position of an attribute node.

To reproduce the problem, use the following VBScript:
set doc = CreateObject("MSXML2.DOMDocument.4.0")doc.loadXML( "<sample a='1' b='2'/>")WScript.Echo "Original XML: " & doc.xml doc.documentElement.setAttribute "a", "3"WScript.Echo "MSXML 4.0: " & doc.xml 

Fix: XSD Uniqueness Identity Constraint is Not Checked When You Use Xsi:type to Change the Type of an Element

In MSXML 4.0 RTM and SP1, if the type of an element is changed to use xsi:type, the unique identity constraint is ignored.

To reproduce the problem, use the following .xsd and .xml files:

Test.xsd
<xs:schema targetNamespace="http://tempuri.org/XMLSchema.xsd" elementFormDefault="qualified" xmlns="http://tempuri.org/XMLSchema.xsd" xmlns:mstns="http://tempuri.org/XMLSchema.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema">            <xs:complexType name="property" abstract="true">                        <xs:attribute name="name" type="xs:string" use="required" />            </xs:complexType>            <xs:complexType name="select">                        <xs:complexContent>                                    <xs:extension base="property">                                                <xs:sequence>                                                            <xs:element ref="option" minOccurs="1" maxOccurs="unbounded" />                                                </xs:sequence>                                                <xs:attribute name="type" fixed="select" />                                    </xs:extension>                        </xs:complexContent>            </xs:complexType>            <xs:element name="option">                        <xs:complexType>                                    <xs:attribute name="default" form="unqualified" fixed="true" />                        </xs:complexType>            </xs:element>            <xs:element name="xTask">                  <xs:complexType>                         <xs:sequence>                               <xs:element name="xTaskProperty" type="property" minOccurs="1" maxOccurs="unbounded">                                     <xs:unique name="selectdefault1">                                             <xs:selector xpath=".//mstns:option" />                                             <xs:field xpath="@default" />                                     </xs:unique>                                </xs:element>                         </xs:sequence>                 </xs:complexType>            </xs:element></xs:schema>
Test.xml
<xTask xmlns="http://tempuri.org/XMLSchema.xsd" xmlns:f="http://tempuri.org/XMLSchema.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:mstns="http://tempuri.org/XMLSchema.xsd">            <xTaskProperty  name="sample" xsi:type="select">                        <f:option default="true"></f:option>                        <f:option default="true"></f:option>            </xTaskProperty></xTask>
Visual Basic code
Dim doc As New MSXML2.DOMDocument40doc.async = Falsedoc.validateOnParse = Falsedoc.Load App.Path & "\t2.xml"doc.Validate

Fix: MSXML 4.0 Leaks Memory When You Clone XML Nodes from Visual Basic ActiveX DLL

In MSXML 4.0 RTM and SP1, cloning XML nodes in Visual Basic ActiveX DLL causes memory leaks. This behavior occurs when the DOMDocument is global.

REFERENCES
For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
818081 INFO: List of Issues Fixed in MSXML 4.0 SP2 (Part 1 of 4)
818084 INFO: List of Issues Fixed in MSXML 4.0 SP2 (Part 3 of 4)
818085 INFO: List of Issues Fixed in MSXML 4.0 SP2 (Part 4 of 4)

Properties

Article ID: 818083 - Last Review: 02/27/2014 21:18:26 - Revision: 2.1

Microsoft XML Core Services 4.0 Service Pack 1

  • kbnosurvey kbarchive kbxml kbinfo KB818083
Feedback