>Thanks to Rick Strahl's utility on West-Wind.com (wwXML) I've been able to see a cursor written to XML. It helps to have some nitty-gritty detail. I heartily recommend it.
>
>I'm looking at implementing it for an import/export (exchange) process. My thinking is to take VFP data and format it as XML. Then, I could (?) create various proprietary formats, such as Excel, and non-proprietary, such as CSV.
>
>Two considerations: the users will want to change what can be exchanged, and it should seemlessly integrate with the database so that the impact of changes is minimized.
>
>The export/import involves related tables. I don't know if it is better to a) create a view that represents the data or relate the tables and scan through each from parent to child, so that I can build the XML hierarchy.
>
>If you have any thoughts, I'd appreciate hearing them. Also, I'm drowning a bit in information, so have started to just dig in. Feel free to tell me RMFM < s>, but please point to which FM. :)
>
>Thanks.

To answer this, you have to consider the data destination. Who is using it and how?

Does the data consumer want to see the denormalized data, or are you translating it to XML purely so it can later be turned back into relational data? IOW, what is the XML for? In the applications that I use XML for, the client program only needs to know the end result of the data, and not the structure and relationships of the underlying tables. By the time it is XML, it is denormalized.

That's not to say that you can't communicate related data with XML as well, but the implementation becomes much more complex. I can personally only think of one situation that you would wnt to do this, and that is if the client wanted to use XQL to query the data before it was translated into any other format. (There could be far more uses, I just don't know of them).


Also, remember that the XML documents created by wwXML are documents that represent a table, not documents that represent the entity that the table was designed to store information about. IOW, if you have a Orders table (or a single record from the Orders table), and use wwXML.CursorToXML to create an XML document from that cursor, the XML document created is really a representatin of a table, where as XML specifically designed to represent an order would be designed much differently (you wouldn't see tags called "FIELD" and "RECORD". For simple implementations this is fine, but if you begin to use XML for serious business communication, be sure you are not relying on wwXML to give you well structured documents. (Not that they are not well structured, just that they are geared toward tables, and not business objects like "Order").
Any time you write a generic routine to be used to convert generic data, you run into this. But the beauty of XML is that the very format of the document can (and should) be tailored to exactly fit the entity of the data it is conveying.

Hope my rambling hasn't confused you.