>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.