XML to/from MV – Part 1

I’ve been doing a lot of work lately with XML data. I’m just importing from XML to MV right now but exporting MV to XML can be the same thing in reverse. Here is part 1 of a multipart discussion on the topic.

When asked “what is the most efficient way of building outbound XML docs and/or parsing/loading inbound XML docs into an MV application”, I’d say the answer depends on your experience.

If you know nothing about tools outside of MV and your only experience is with BASIC, then you can create XML as follows:

DOC= ''
DOC<-1> =''
DOC<-1> = '

'
DOC<-1> = '' ...

That can get very tedious. These days most XML is done using tools, often free.

Personally I use .NET tools where I generate code from XSD files, the schema definitions. That often only takes a couple minutes. Then I do what is called serialization and de-serialization, which is creating XML documents using the generated code or populating variables with data from XML. This involves a one-to-one mapping of MV fields to the XML definitions. The code might look like this:

XmlCustomers xcusts = DeSerializeCustomers(); //from XML
DbmsCustomers dcusts = new DbmsCustomers();
foreach( XmlCustomer xcust in xcusts ) {
DbmsCustomer dcust = new dcust(); // create a single customer object
dcust.ID = xcust.ID;
dcust.address.street = xcust.address.street;
dcust.address.city = xcust.address.city;
dcusts.Add(dcust); // add single customer to collection of customers
}
dcusts.WriteToDbms(); write all customers to DBMS

Note from the above example that MV isn’t mentioned – the DBMS can be any MV or non-MV DBMS, or even a web service where we export the data without knowing what the DBMS or internal structures look like.

Details add to the coding time. For example, what if the customer address is not really stored in MV in the customer record even though the XML file has it all in one place. That’s not a problem. The dcust object above is just a jumping off point. When we execute WriteToDbms, the code will pull the address info into the MV files, perform validation, setup cross-references, or whatever else is required.

Other details involve data format, where you may need to convert from an external DateTime format to MV internal date format. Or there may be nested classes where you first loop on Customers, then you loop on Contacts within those customers, then you loop on phone, email and other contact details for each contact.

Generating XML is just the opposite, where we pull from MV into one or more objects, simply assign that object data into an XmlCustomer object, add XmlCustomer objects to a XmlCustomers collection, then serialize the collection to XML in one statement.

A project I’m working on now is to generate MV files and fields from XSD schema so that I can move data directly from the XML objects to the DBMS objects, and pump that directly into temporary MV files. Then someone can write BASIC code to move MV to MV without any XML involved. That BASIC code might look like this:

OPEN 'XML.CUSTOMERS' TO XCUSTS ELSE STOP
OPEN 'CUSTOMER-MASTER' TO CUSTMAST ELSE STOP
READ XREC FROM XCUSTS,NEXTID THEN
CREC = ""
CREC<1> = XREC<3>
CREC<4> = XREC<2>
CREC<21> = XREC<5> * 100
WRITE CREC ON CUSTMAST,NEXTID
END ELSE NULL

If anyone is interested in this, please let me know. I can use it for my own projects but I can see lots of applications for it.

In Part 2 I’ll discuss how XML relates to MV dictionary definitions and dynamic arrays … or rather, how it doesn’t.

In a Part 3, I may discuss XML capabilities built-in to some MV DBMS products, but articles like this require a lot more effort. I invite people familiar with each DBMS to write a guest piece here, to explain how to create and parse XML with their tools of choice. What comes to mind right now is the %XML library in Caché, and the XML API and XML/DB tools in U2.

Suggestions are welcome for other related content.