Many Questions

[Bryce L Nordgren <bnordgren@fs.fed.us>]

Greetings!  First let me say "job well done".  From what I've seen on the
OASIS wiki, the units ml is quite a capable piece of work, seeming to cover
all the bases.

My biggest curiousity/concern is <Unit/>, which contains no <Dimensions/>.
I gather that <Quantity/> is supposed to be a grouping of units, all of
which have the same dimensions and which measure along the same conceptual
axis.  My XML Schema skills may be a little lacking, but isn't the
multiplicity of <UnitReference/> set to one?  Does that mean that there's
only one unit per quantity?   What if I have lots of units to
measure...well, "length"? :) I think this is an easy fix
(maxOccurs="unbounded").

Secondly, if <Dimensions/> is to live with <Quantity/> instead of with each
individual <Unit/>, an external application (like a spreadsheet) will be
unable to accept a simple <UnitReference/> to get at the dimensions.
(Because <QuantityReference/> is optional inside <Unit/>.)   It seems to me
that this is backwards.  <Dimensions/> should always be accessible from
<Unit/>s with a minimum amount of work, to enable rapid dimensional
checking by the application (probably the most frequent operation).
Otherwise, a unit-enabled application must have access to a complete
<Quantity/> database and will continually be querying "Which quantity
contains Unit X?"  before it can even check the dimensional consistency of
the expression.   (Yes, I know the situation is not quite so bad if the
<QuantityReference/>s are provided, but all applications must be *prepared*
to query incessantly.)  A correllary is that all <Quantity/>s referenced
from the same <Unit/> must contain the same <Dimensions/>.  Long story
short, can we please put <Dimensions/> in <Unit/>? :)

Thirdly, has any thought been given to explicitly making the system
extensible?  For instance, adding (or allowing to be added) a
"monetaryValue" child of <Dimensions/>?  Monetary value (e.g., currency,
stocks, etc.) is the only "extra" I can think of right now, but there may
be others.  Salient characteristics are: it's orthogonal to the SI base
quantities and is frequently combined with them (cents per mile, dollars
per gallon, dollars per hour, dollars per person-month, dollars per bag of
gummy bears.)  Currency isn't special; it's a unit just like any other.
It's just not a physical unit.  Hmmm...if you make <Conversions/> into
something with an external reference, someone could even setup a web
service which always exported a <Float64ConversionFrom/> (horrible name)
element populated with the current exchange rate.  Probably should add a
timestamp too.

Urgh--distracted.  In any case, it seems that adding currency would be a
trivial modification.  If you elect not to, you should feel encouraged to
"leave a hole" so that others can.  :)  Perhaps something to consider is
specifying "conformance levels" where implementors could elect to handle
"physical units" or "physical units+currency" or "currency".

Is there an "explanation document" in the works, which might explain how to
handle certain use cases?  For instance, I can have "ppm of CO2", which is
not at all interconvertable with "ppm of Ar", and which is only
interconvertible with "ppm of O2" and "ppm of CO" via a chemical reaction.
(e.g. <SpecialConversion/>)  Are these in fact different units?  Is "ppm" a
<Quantity/> which can contain many mutually non-interconvertible units
(CO2, Ar, CO)?  Should <Quantity/> be heirarchical: "scalar begat
concentration which begat fractional, percent, ppm, ppb, and ppt"?  This
might suggest that "Quantities" would have conversions too (e.g. all
"concentrations" would have a reference representation from/to which all
children could convert).

Interesting...this also suggests that <Quantity/> is orthogonal to <Unit/>.
While one cannot describe conversions between "ppm CO2" and "ppm O2"
without a chemical reaction, one can easily describe the conversion between
"ppm CO2" and "ppb CO2", because they are merely different expressions of
the same molecule's concentration.

All in all, though, good job!  When is the final version scheduled for
release?  Please forgive my senseless ramblings.

Bryce Nordgren
Physical Scientist
Rocky Mountain Research Station
USDA Forest Service