>>>>>Doubtful. VFP's internal XML parsing is blazing fast. I'm not sure if they're using MSXML or not internally, but if they are they are low level early binding to it, which will be much faster than anything we can do with the late bound MSXML objects.
>>>>
>>>>Internally, XMLTOCURSOR uses MSXML, and CURSORTOXML parses it itself (at least I think it does; haven't actually looked at the code myself). This is would partially explain the speed difference between the two functions.
>>>
>>>If it's done manually you always have to worry about keeping up with XML standards - I'm well familiar with this since this is what wwXML does too. But export is considerably easier than import so using MSXML for importing is likely to be a requirement in order to deal with schemas/namespaces etc....
>
>Not really - not for VFP anyway. The text reader is supposed to be very fast and for cursor parsing it's probably a good tool. But I wouldn't want to call into .Net (ie require the CLR around) just for doing XML conversions.
>

Good point. Maybe I'm jaded, but my assumption is that the CLR will be installed on everyone's Windows machine anyway in a year or so, courtesy of Microsoft. But I bet you're correct in that the overhead of calling through the CLR would outweigh any performance benefits once you get there.


>Also the XML Reader is non-validating (at least some of the classes anyway) and I'm not sure how this works with the various attributes of the cursor etc. I haven't played with it, so I can't say from first hand experience.
>
>Personally, I don't send that much data around that the speed of any of the XML conversion routines have ever been a problem. If you're sending more than a few hundred k of data around one needs to rethink the application including potentially chunking up the data at least in a distributed environment.
>

I agree with you about rethinking the app. The only valid reason I can see for returning a really large chunk of XML would be in reporting/data transfers, where the results of a query could be sizable. Still, you could break the data into small parts and parse/reassemble them on the client side.


>The DOM model works fine on sizes around 1 meg and I've not seen degradation even on larger files but it can be resource intensive...

Thanks for the feedback. I'll keep an eye on the West-Wind site for information on XML parsing as new tools and techniques appear in the coming months!

>
>+++ Rick ---