Input and Import

If you have existing validation routines for import and data entry, reusing them for XML import will save you a lot of work. As I said earlier, there are limits to schema validation. If your application needs to validate order item numbers by looking them up in a database, you'll need to call this code when you import XML data. A well-designed system might use the same modules for validating an imported purchase order that it does for one entered by a human operator. If your system isn't coded this way, building in XML support might be a good opportunity for centralizing and cleaning up your validation logic.

The specific changes you need to make in your code depend on how you import data from the user's perspective. Do you provide a batch import from a command line, or is it driven by a user interface where the user selects files to import? If by batch it may make sense to build a completely separate program to import XML. If it's by a user interface, the determining design factor will probably be the degree to which the logic for reading the source, validating it, and storing it is segregated and modular. As you could see from the code examples, the logic for loading an XML document and retrieving data from it can be fairly involved. If your code for reading, validating, and storing is already mixed together in one module, adding XML calls is only going to make the code more complicated and less maintainable. You might be better served to code a completely separate module for XML import. Or you can again take advantage of the opportunity to redesign your code and clean it up a bit.

If the functions are already nicely segregated and the code is modular, you can probably code a specific XML import routine to load the data into the same data structures used when reading from other sources. You can then pass these data structures off to existing validation and storage routines and be done with the job.