Microsoft KB Archive/818083

From BetaArchive Wiki

Article ID: 818083

Article Last Modified on 8/12/2005


APPLIES TO

  • Microsoft XML Core Services 4.0 Service Pack 1


SUMMARY

This article is part 2 of 4 in the series of articles that documents the bugs that are fixed in Microsoft XML (MSXML) 4.0 Service Pack 2 (SP2).

The following bugs have been fixed in MSXML 4.0 SP2:


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>

back to top

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:

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>

back to top

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>

back to top

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>

back to top

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 

On Error Resume next

    set xmlDoc = createObject("MSXML2.DOMDocument.4.0")
    xmlDoc.async = false
    xmlDoc.validateOnParse = false

    xmlDoc.load("t.xml")
    set pErr = xmlDoc.parseError
    WScript.Echo "LOAD ERROR : " & pErr.reason

    set pErr = xmlDoc.validate()
    WScript.Echo "Validate() Error: " & pErr.reason

back to top

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

back to top

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.DOMDocument40
doc.async = False
doc.validateOnParse = False

doc.Load App.Path & "\t2.xml"
doc.Validate

back to top

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.

back to top

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)



back to top

Keywords: kbinfo kbxml KB818083



Send feedback to Microsoft

© Microsoft Corporation. All rights reserved.


Retrieved from ‘https://www.betaarchive.com/wiki/index.php?title=Microsoft_KB_Archive/818083&oldid=381832’
the Creative Commons 3.0 ShareAlike (except the Microsoft KB Archive).
Powered by MediaWiki