This page lists several ideas for desired improvements to DAVE-ML that are needed to make it a more viable means for distributing and exchanging flight dynamics models. This page is provided for convenience of the DAVE-ML community, but doesn’t represent any commitment by NASA or AIAA or anyone else to achieve these goals. Help (volunteer effort, funding, advocacy) would be helpful, as always.

DAVE-ML Development Roadmap (notional)


Additional fileHeader subelements
  • Add an optional classification subelement; contents will be defined by the particular user community.

  • Add an optional dataAssumptions subelement; this text field should specifically mention limitations of the encoded model for quick reference and documentation.

  • Add an optional tag subelement; this would be a string to be defined by the model creator. This string would serve to identify several DAVE-ML files as being part of the same version of an aircraft model, sort of like a tag in a versioning system.

  • Add an optional type subelement, if we can agree on a limited set of UTI strings to choose from. This is a response to an earlier sim-stds mailing list posting by Dennis Linse in which he expressed a desire to be able to distinguish types of DAVE-ML files, by aircraft type.


Multidimensional output tables

Add support for storing multiple function values in a table, both gridded and ungridded, such that only one independent-variable search/normalization is required to find several output values. This would be useful to save both DAVE-ML file length and run-time performance, and addresses the suggestion made by Dan Newman in a sim-stds mailing list posting in May 2010 concerning ungridded tables.

Vector/matrix support

Add the ability to define inputs and outputs as vectors and matrices. MathML already supports vector and matrix types; only need to figure out how to deal with these. Geoff Brian has a draft AIAA paper that discusses more specifics; it will be presented at the 2011 AIAA Modeling and Simulation conference in Portland.



Add sufficient information to the DAVEfunc top-level element to be able to re-use such a model by a yet-to-be-defined higher-level element. Sort of like a library block; this may lend itself to a standard library of common aerospace components (actuators come to mind).


Dynamic model wrapper

This will probably be a new top-level element, such as DAVEdyn, that wraps around a static DAVEfunc to add state variables, either discrete or continuous, and will contain sufficient meta-data that a processing system will know how to implement it. This will also require dynamic check cases that are considerably larger than the staticShots currently supported.



This release will introduce yet another top-level element, such as DAVEmodel, that can embed multiple dynamic sub-models (DAVEdyns) or static sub-models (DAVEfuncs) or even other DAVEmodels to create a true system-of-systems hierarchy.

Want to help? Help define any of the above roadmap elements, or take a crack at one of these opportunities. Discussions should be posted to [email protected]

Native DAVE-ML editor

The DAVE-ML community needs a multi-platform DAVE-ML native editing application. This is a major project! It probably could be based on the open-source Eclipse integrated development environment which is extensible. It would be nice if the XML source were completely hidden from the user, and interactive 3-D graphics were available to view data tables.

User’s manual

A reference manual for DAVE-ML is prepared for each version of the DTD, but is pretty dry reading. We would all benefit from a booklet that describes typical development and use of a DAVE-ML model, in terms a journeyman simulation, aerodynamics or modeling engineer would understand, including how to get set up to use one or both APIs (Janus or DaveMLTranslator).