The Mifos Data Exchange XML Schema

This document contains notes and information related to the the Mifos Data Exchange XML (MDEX) schema created for the data migration proof of concept project (to read Center data into Mifos) The MDEX schema in RELAX NG format can be found here

Schema Design Choices

One basic decision about how to construct the schema relates to how much specificity we want in the schema information. First let's address what is meant by "specificity". When defining what the content of an XML element will be, the default is for it to be an unbounded text string. If the element is supposed to be the "day of the month" on which a meeting occurs, then constraining the element to be an integer value between 1 and 31 makes clear what the intent of the field is and insures that data can be validated.

In general the more specificity the better, but we need to be aware of the tradeoff. The benefit of more specificity is that reading the schema document will provide information up front about what data is valid for migration (without having to look in the Mifos code or database schema). The drawback is that more specificity (including things like the length of a text field) means that the MDEX schema is one more location in which this information is represented and must be maintained (in addition to the SQL schema and possibly Java validation code). Whenever the information is changed in the SQL schema, someone will have to remember to update it in the MDEX schema too.

It is worth considering what happens if we do not include information like field lengths. In this case, a string which exceeded its field length should be caught by Java based validation code when an object is created during import. If validation is not present in the business logic (for example, it is only present in the GUI validation logic) then it must be added to the business logic or else a database level error could occur during import.

Another factor in schema design is the issue of customizable values. There are custom fields and customized lookup values. Using a fixed schema, there is little that can be validated based on the XML alone. In this case the validation (for example making sure that a particular customized field exists for a given business object) would need to be done at object creation time. For lookup values (such as loan purpose) the same is true. Since the list of valid values can be changed for a given Mifos installation, the schema must be relaxed to allow any text value and then do the validation at object creation time to make sure a given value is valid.

One possibility for handling customized values would be for Mifos to provide the capability to generate a schema where the part that constrains values includes the custom values that have been defined in Mifos.