I think that Martin and Ed have made some very good points about the subtleties of unit and dimensional analyses, and I'm going to repeat an old suggestion of mine in the context of this discussion.
Part of the problem is that Pedro's approach makes total sense within the context of photon spectra of sources, where things can be interconverted using some combination of (1) unit analysis and (2) the dispersion relation nu * lambda = c. But it doesn't extend so easily to general astronomical data where, as has been pointed out, the UCD and possibly other metadata may be needed to do a conversion or to determine whether a conversion makes scientific sense.
I think in the DM context it's important to distinguish between conversions which are simple scaling (pc to AU to km) and conversions which in principle require a UCD (even though you can get away without one if you are in the spectral context and using nu * lambda = c). The UCD based conversions are domain and context specific and should be in software associated with particular contexts (e.g. a spectral packag) while the basic units scaling conversion is general and should be in general software.
So to me the question is: how can we support the very useful functionality of Pedro's tool in the spectral domain without boxing ourselves into a corner that won't generalize well?
I've argued with Pedro in the past about this distinction between dimensional analysis as - I think it was Ed said this? - the answer to the question 'are these things compatible' with no numeric factor, and unit analysis where the numerical factors are included.
I would restate
some of the recent discussion as alleging that Pedro's scheme is
really unit analysis dressed up in the clothes of dimensional analysis,
and I assert that if you restate that scheme as "reduce all units to
their unprefixed SI base unit representation", so that
mJy -> 10^-23 kg s^-2
10^-11 erg cm^-2 s^-1 keV^-1 -> 6.215 10^1 m-2 s-1
and then rename kg = "M", s = "T", m = "L" so that it's 1.E-23 MT-2 and 6.215E+01 L-2T-1 you have exactly Pedro's scheme. Given that, why not skip the renaming. If we require (possibly as additional metadata) that an SI base representation of the units be provided
that's really trivial for Pedro's software to parse into his L-2T-1 format, but it can also be used by unit analysis software. I'm just saying, even if we have redundant metadata (unit and sifac/siunit) we don't need redundant DIFFERENT string syntaxes. If we're going to have a string syntax for the "dimensional" analysis, why not use the SAME syntax that we use for general unit analysis, since then other people's clever unit software can handle either UNITSCAL/UNIT or SISCAL/SIUNIT with the same parser.
If clever unit software becomes widespread and standardized we maybe eventually can drop the SI.. version.