>>For the life of me I can't figure out, despite many statements like you make here, how "XML" is a "data engine".
>>
>>What is it that makes XML a "data engine"?
>
>.NET "dataset objects" use XML as their "internal" protocol. These "datasets" contain one or more tables that can also have relations. This set of "classes" probably bears a closer resemblance to the Access "data engine" (ie. JET), which is also object-oriented, than it does to the FOX data engine.
>
>In practical terms, it is actually easier to "point" at the "data engine" in Access (JET), .NET (System.Data), Delphi (BDE) ... than it is in VFP, which is the sum total of all the various DDL/DML statements, commands, and related functions. I would actually consider the VFP ODBC or OLEDB driver as a more "concrete" instance of the VFP data engine.

I *may* be getting the picture but...

I understand "XML" to be just string information that happens to have a standard 'format'.
Am I correct that XML (strings) can be 'decoded' by VFP (XMLTOCURSOR()) without the need/benefit of an "engine" and 'encoded' (CURSORTOXML()) similarly?

Then .NET essentially does those simple things AND MORE (e.g. relations, adding records, updating records, deleting records) and the thing(s) that do that is/are called "the engine"? ...So there exist databases with tables that are filled with XML 'strings' (describing/being the data) and this/these "engine" take care of all this stuff in them?

Thanks Gerry