Thanks, Rick. Thanks to everyone who's answered so far. I've just been quietly collecting the responses and then was going to jump back in, but I had to respond to this one. :^)

> I think this is the wrong question to ask.

I've gotten lots of great replies (including yours), but you're the only one who seems to think I'm asking the wrong question. Why? 2-3 years ago, it was common (well, not common, but the best choice?) to have our COM objects return ADO recordsets, since many kinds of clients (at least on Windows) could consume them. In the narrow part of my question that you find wrong, I was basically asking why people felt that XML was a better way of passing around that info.

As I said, I got lots of great answers that helped me see how VFP folks are currently using XML and why it is an improvement in this role over ADO or other choices (CSV, etc.). So, in my opinion, it certainly wasn't the wrong question. Especially if my goal was to collect lots of good examples of how XML is being used in VFP applications.

The point is, there are other ways, in most cases, to do what people are doing with XML. They may their limitations, but then so does XML. Nothing is a free ride. So, I was just hoping to provoke some thought to hear WHY people are choosing to use XML vs. just hearing that they're using it because it's the latest pervasive technology. And I think I succeeded. Knowing the "why" was important to me. Sorry it was the wrong question from your POV, but it worked for me. :^)

Maybe I should have emphasized the WHAT ARE YOU DOING WITH XML part of my question over the WHY IS IT BETTER THAN ANY ALTERNATIVES part of my question. But then, I didn't realize questions were being judged as right or wrong. I figured that was reserved for answers. :^)

>>Hi. I guess you can say I'm taking a survey. I would like to hear from those of you who are actively using XML, especially where VFP is involved. What are you doing with it? Why is it better for your situation than any alternatives, especially ADO?
>
>I think this is the wrong question to ask. ADO and XML are not really at odds with each other. I personally think ADO is not exactly smart technology, but given that Microsoft pushes it so hard and VB etc. have that as the primary choice it's hard to ignore. I still question why you'd use ADO in VFP unless you are working in COM environment that needs to interact with other COM objects wihch is a very specific scenario. For Web applications I believe XML is a better fit and becoming more so iwth the .NET platform.
>
>XML's strength is it's flexibility. You can do a lto more with XML than you can with ADO. You can move structured data around and you can configure how you want that data to look and work. And as a bonus it works with any platform that supports an XML parser which is just about any platform.
>
>You can persist table based data, objects, hierarchical objects, or anything you decide to encode on your own. It's text - it can be easily created and parsed by just about any language, Windows based or otherwise...
>
>It can be used in the browser. ADO - not without major configuration issues.
>
>I think ADO+ will change this with much better XML support, but I still believe that custom XML is a much better fit in typical Web scenarios. One thing to remember is that we're going to be looking more and more at Web serivces. These services will be very specialized and they're not going to fit a data model exactly. XML will be able to conform to this much better than a table based interface like ADO.
>
>I personally like XML because it's a good fit for so many things not just data. For example, I directly map my business objects into XML and that automatically makes the business objects sharable over the Web for consumption by a browser or by other client applications. I use XML for things like persisting object state, for moving data between C API routines and Fox Code, for OLE drag and drop operations between two applications sharing data, for holding configuration data in my applications (with auto persistence), for geeneric TreeView display (gen XML then pass it to a tree class that can display it), for providing table of contents to Web sites - the list can go on. Same set of tools services all of these areas which makes development easy.
>
>The only downside to XML I see is potential performance issues, but this may or may not be important. Smart applications don't pass tons and tons of data back and forth (or if necessary chunk it) so this is not a typical issue. One mroe problem that's less obvious is data format issue with XML - XML doesn't do well with binary data and encoding can be problematic. But these are issues that can be sidestepped with workarounds.