Functional Requirements
The technical end user who has an application that doesn't speak XML more than likely needs the solution to do one or more of the following:
Convert an XML-formatted file to a flat file
Convert a flat file to an XML-formatted file
Convert an XML-formatted file to a CSV file
Convert a CSV file to an XML-formatted file
Convert an EDI-formatted file to an XML-formatted file
Convert an XML-formatted file to an EDI-formatted file
A user may want the solution to support other formats, but CSV, flat file, and EDI should handle most cases. For example, an end user may also need to get data out of a database (relational, hierarchical, or otherwise) and put it into an XML format, or go back the other way. Sorry, but these types of problems are a bit beyond our scope. I will, however, give in Chapter 12 an overview of some approaches for doing things like this. When I present the approaches, you'll understand why problems like this exceed our scope a bit.
The developer who has an application that doesn't speak XML has some fairly simple requirements:
Enable the application to export data in an XML format
Enable the application to import data from an XML format
The word “an” is very important here. I don't say “a specific XML format”; I say “an” XML format. Why? Because once we have data in an XML format, it is fairly easy to convert it to another XML format. You want to make your life simple? Don't try to anticipate all the XML formats your users will want. Give them one, and let them convert. I'll have more to say about this later.
Those are the primary functional requirements. Both groups may have a secondary functional requirement to be able to validate the format of an XML document (which conventionally is referred to as an instance document). When validating an instance document, the format of the document is usually defined in an XML 1.0 Document Type Definition (DTD) or a schema written in the World Wide Web Consortium (W3C) XML Schema language. Both of these define things such as the Element and Attribute names used in the document and the overall structure of the document. The W3C XML Schema language allows documents to be defined in much greater detail than is possible with a DTD. These will both be discussed in Chapter 4.
Validation may need to occur either before the document is read or after it is produced. For going to and from EDI, end users may want to check that the EDI-formatted file complies with the relevant standard either before they read it or after they write it. The approach presented in this book satisfies most such requirements.
Some other functional requirements have do with enabling business applications to support the exchange of business data with other organizations electronically. Those requirements are within the scope of this book, and I'll discuss them in Chapters 12 and 13.
So, we should be pretty clear by now about what we want the solution to do. We now need to figure out how we want it to do it.