At 5:50 PM -0500 9/29/04, Jon S Berndt wrote:
I've been looking at the data table format for DAVE-ML, for example:
<dataTable> <!-- Note: last breakpoint changes most rapidly -->
9.5013e-01 6.1543e-01 5.7891e-02 1.5274e-02 8.3812e-01 1.9343e-01
2.3114e-01 7.9194e-01 3.5287e-01 7.4679e-01 1.9640e-02 6.8222e-01
8.2141e-01 4.1027e-01 2.7219e-01 2.0265e-01 3.0462e-01 8.5366e-01
4.4470e-01 8.9365e-01 1.9881e-01 6.7214e-01 1.8965e-01 5.9356e-01
For JSBSim, we have been working on moving our aircraft config file format closer to DAVE-ML, where applicable. Our table format is already similar to the above, though in our case we have the breakpoints as part of the table data.
As we discuss the newer XML format we intend to use for JSBSim, the question has been raised about the pros and cons of the above format. For one, it is nice to be able to look at the data and see what it means without a bunch of tags obfuscating the data. The above format also is conducive to import/export with spreadsheet programs. However, if an editor or automated process is to be used in authoring a DAVE-ML file (or in our case a JSBSim file) we also ask if there is a greater benefit in using a more "whole" XML specification, such as:
<tr> <td> 0.1 </td> <td> 0.34 </td> </tr>
<tr> <td> 0.2 </td> <td> 0.49 </td> </tr>
<tr> <td> 0.3 </td> <td> 0.57 </td> </tr>
<tr> <td> 0.4 </td> <td> 0.68 </td> </tr>
<tr> <td> 0.5 </td> <td> 1.75 </td>< /tr>
My goal in the current DAVE-ML table design was to make it as efficient as an ASCII implementation could be, since these tables comprise the majority of data in most "heavyweight" simulations. The interpretation of rows/columns/higher dimensions comes from the surrounding XML structure in which this table is embedded; the table doesn't (usually) stand alone.
As you are probably aware, DAVE-ML doesn't embed breakpoints directly in the tables because these are typically reused - for example, the angle-of-attack breakpoint set is often used in dozens of tables. Again, the surrounding XML structure contains a reference to the appropriate breakpoint set.
I notice the use of HTML row/data delimiters above; those can easily be achieved for a given table in an XSL transformation stylesheet so that a browser, for example, can display a DAVE-ML table properly. We didn't really expect to have to do that, however.
I must confess that Bruce Hildreth has been urging an example of an "ungridded" table, which the DAVE-ML format supports but has to date been ignored, sort of like:
0.1, -4.0, 9.5013e-01 <!- Mach, alpha, CL ->
0.1, 0.0, 6.1543e-01 <!- Mach, alpha, CL ->
0.5, -4.0, 2.3114e-01 <!- Mach, alpha, CL ->
0.6, 0.0, 4.1027e-01 <!- Mach, alpha, CL ->
where you'll notice we embed the independent value(s) in the data record, ahead of the dependent value. For this type of data, there is no breakpoint set per se. This is more in line with the "whole" XML implementation you're considering.
I guess you could go hog-wild XML and generate something like
but that seems to be overkill to me.
Also note the (optional) use of the modID attribute, so we can tag each data point to a particular source data document and thus know where it came from or why it was changed.
[IMPORTANT NOTE TO AIRCRAFT DESIGNERS: do not rely on the table above to design your aircraft. It is intended for illustrative purposes only.] :)