In a recent project, we used Excel spreadsheets to capture the data dictionaries for our functional requirements. The project actually had 22 data dictionary sections, each with about a hundred data points described in them. Each data point had on the order of twenty properties that the client needed to know about. It included not only how to present the data entry field, but how to bind it at runtime to business objects, how to transform the user input before presenting the data to various back-end systems, validation, and a few other rules.
Excel spreadsheets can be saved off as XML, a fact which we leveraged. Our analysts filled in the Excel spreadsheets, identifying all the data points and the typical properties of each. After that, we engineers filled in bindings and a few other more technical details. Later, we transformed our Excel-document data dictionaries into a custom XML format (a Domain Specific Language or DSL) using XSLT. Finally, we compiled those extracts into our client application as a resource (one for each dictionary) containing all the client metadata for that dictionary.
Divorcing ourselves from the broken notion that XAML is WPF, and with just a little more time (on the order of days), we could have codified our DSL into a set of .NET classes. By doing this, we could have converged our data dictionary metadata on XAML. In effect, this would have turned metadata directly into runtime business objects. These business objects would have served as the content for our WPF-based LOB data entry forms. In turn, this would have greatly simplified a number of complexities, especially around the problem of indirect data binding. The end result would have been a more maintainable code base, and even faster running code.
