Moving from DOM to SAX : XML SOAP

Hiya,


Is there any documentation out there (preferably from Microsoft) for
developers that want to move from MSXML_X DOM to MSXML6 SAX? Notes on
compatibility, performance guide, etc...?

I have been searching using goggle, without much success...


Regards,

Vivek

* Vivek wrote in microsoft.public.xml:
>Is there any documentation out there (preferably from Microsoft) for
>developers that want to move from MSXML_X DOM to MSXML6 SAX? Notes on
>compatibility, performance guide, etc...?

Your question is too vague to provide a good answer. If your application
does not need to maintain considerable state information, you will find
that SAX-based access is considerably faster and/or consumes less memory
than keeping the whole tree in memory. I don't see how compatibility can
be a concern here.
--
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Yes, right now, two sets of DOM trees are being utilized to store
application specific data into an XML file where the first DOM tree is
being used as the XML file that stores and saves the final XML file and
the second DOM tree for parsing sets of XML data from C++ IStreams (for
validation purposes) before it is appended into the first master DOM
tree with the DOM1.AppendChild(DOM2.GetDocument() [for example].

I did not design this, so yes, I understand this is certainly NOT the
best way of doing things.

Bjoern Hoehrmann wrote:
> * Vivek wrote in microsoft.public.xml:
>
>>Is there any documentation out there (preferably from Microsoft) for
>>developers that want to move from MSXML_X DOM to MSXML6 SAX? Notes on
>>compatibility, performance guide, etc...?
>
>
> Your question is too vague to provide a good answer. If your application
> does not need to maintain considerable state information, you will find
> that SAX-based access is considerably faster and/or consumes less memory
> than keeping the whole tree in memory. I don't see how compatibility can
> be a concern here.