Requirements
The general requirement for this utility is to convert a CSV file containing one or more logical documents to one or more XML instance documents, each representing a single logical document. This is a significant improvement over the utility presented in Chapter 3, which was restricted to handling a single logical document. In addition, many of the restrictions on both the CSV file format and the grammar of the resulting XML document are removed. Here's a summary of the required functionality.
Inputs: A CSV file in uniform Row/Column organization, that is, each row has the same column entries. Records are of variable length, and columns are separated by a specified terminator. Column contents may be delimited by a text delimiter character in the first and last characters of the column. The input CSV file may consist of more than one logical document. The second input is an XML file description document (as discussed in Chapter 6) describing the CSV file and the grammar of the XML document to be produced.
Processing: Each input CSV row is written to an Element whose name is derived from the file description document. Each column in the row is written to a child Element, with the name also derived from the file description document. Column content is converted to Schema data types as specified in the file description document. Empty columns do not create Elements in the output document. Processing breaks occur on a new logical document and optionally on a new trading partner.
Outputs: One or more XML instance documents, each in a single file. The root Element name is derived from the grammar in the file description document. The file name is formed by appending a three-digit sequence number to the root Element name and adding the extension .xml. If break on trading partner has been specified, the documents for each trading partner are placed in a separate subdirectory. The subdirectories are named according to the trading partner IDs in the Partner Break column.
It may be fairly obvious why we want to create a different XML document for each logical document in the input CSV file. However, it might be helpful to review why we might want to segregate the XML documents for different trading partners into different directories. Despite the proliferation of “standards” (remember the old line, “I love standards, there are so many to choose from”), it is still customary for different trading partners to require equivalent business data to be processed using different formats. Even when they choose, for example, the same version of a UBL Order, they may use it differently. Given that, we might want to apply different XSLT transformations for the documents we send to different trading partners. Even if the documents are exactly the same format (which is unlikely), we might still want to segregate instance documents by destination since each trading partner has a unique network destination and perhaps uses different file transfer protocols, security measures, and so on. Separate directories facilitate this segregation.