Lists Home |
Date Index |
Thomas B. Passin writes:
> > <?xml version="1.0" encoding="UTF-8"?>
> > <aircraft>
> > <elevation>12000</elevation>
> > </aircraft>
> Say I want to compare the elevation to the minimum allowed by FAA
> regs for that location.
First, a pedantic note (not addressed to Thomas; I just happened to
pick his message to join the thread) -- the height of the ground, or
something sitting on the ground, is 'elevation'; the height of an
airplane, or something else not sitting on the ground, is 'altitude'.
Now, if I were looking at this in an archive 20 years from now, here
are the questions I would want to answer:
- feet or meters?
- above sea level or above ground level?
- indicated (pressure) altitude, density altitude, or absolute
If I have something like
(or the equivalent from an external schema) I'm really no further
ahead; in fact, I've come to the conclusion that raw datatyping like
this is close to useless for most applications. You could make a much
better argument for xml:unit (or the external schema equivalent)
This kind of thing would avoid no end of confusion and bugs for
engineering, scientific, and financial XML applications (to name only
three fields), but even then, it leaves most of my questions
unanswered. In the end, I need something human-readable, not
machine-readable, to help me make sense of this (we cannot fire the
technical writers yet):
The absolute altitude of the aircraft above sea level, in feet.
A version of that information could be crammed into the element type
name if you don't like put all your faith in external documentation:
That doesn't help software to read the data, but it helps me *write*
software to read the data (we cannot fire the coders yet, either).
In FlightGear, we've switched to using standard unit abbreviations on
the end of all element type names after some nasty bugs and a lot of
unnecessary confusion. Here are the classic six degrees of freedom
serialized to XML:
> On the other hand, with many of these strong-typing-desiring applications,
> the data probably will not live on. It is ephemeral, designed for one short
> transaction and never to be seen again.
I agree. Data typing may have some value in the specific field of
All the best,
David Megginson, email@example.com, http://www.megginson.com/