Whatever specification was chosen had to be able to maintain backwards compatibility with previous files using minimum programming effort; * extensibility: Initial specifications invariably become modified during implementation. Extensibility ensures an ability to handle unforeseen conditions revealed late in the design or implementation process, and for adding features at a later date; * easy-to-understand: The specification must allow the user to express the problem in the language of the trades. For example, joints should be designated ''joints'', not just a row of numbers, etc.; * modularity: The data interface software should be independent of the application code base; * easy-to-implement: Compiler construction tools provide the most flexible and powerful solution. However, a considerable amount of expertise is required for deployment (compiler construction is often graduate level computer science), possibly overkill for relatively simple data definition tasks; * self-documenting: Problem-specific details should be implemented in such a way that the user can read the input data independently of the application, and if necessary, fix or modify the data. The user should be able to understand not only the data, but how the data are employed. This requires a text-based format. * maintainable: Software is often maintained by programmers other than the original author. The implementation should allow novice programmers to modify or extend the code.