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
</dataTable>
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:
<dataTable>
<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>
</dataTable>
Jon Berndt
Jon,
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:
<ungriddedTableDef>
<dataPoint modID="A">
0.1, -4.0, 9.5013e-01 <!- Mach, alpha, CL ->
</dataPoint>
<dataPoint modID="A">
0.1, 0.0, 6.1543e-01 <!- Mach, alpha, CL ->
</dataPoint>
<dataPoint modID="A">
0.5, -4.0, 2.3114e-01 <!- Mach, alpha, CL ->
</dataPoint>
<dataPoint modID="B">
0.6, 0.0, 4.1027e-01 <!- Mach, alpha, CL ->
</dataPoint>
</ungriddedTableDef>
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
<fullXMLTable>
<dataPoint modID="A">
<IV name="Mach">0.1</IV>
<IV name="alpha">-0.4</IV>
<DV name="CL">9.5013e-01</DV>
</dataPoint>
...
</fullXMLTable>
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.] :)
-- Bruce
