Units discussion

[Markus Demleitner]

On Fri, Jan 27, 2012 at 02:54:47PM +0000, Norman Gray wrote:
> On the IVOA wiki page about units
> <http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/DiscussionOnVOUnits>,
> Markus and I appear to be reaching rough consensus on what's
> required (is that fair, Markus?).
Hmha, maybe the one point deserving the attention of the list is (and
I think it's less fundamental than it might seem at first) and maybe
a brief discussion here is this:

[quoting Norman on the wiki page:]

# One possibility is that we should aim for a minimal grammar (in which
# case the CDS grammar is probably the most nearly minimal of the
# three), or a lenient but still well-defined one (in which case the
# FITS covers almost all bases, even though it's not a strict superset
# of the others). I'd push for the latter: it's well-defined, but most
# nearly compatible with everyone, plus it's flexible enough that
# people don't have to try to memorise what is and isn't permitted
# (principle of least surprise).

I, on the other hand, maintain that having a simple grammar that
uniquely defines how a given unit is expressed is preferable on
grounds that VOUnits is, in effect, part of the VOTable spec, and
people will, as soon as they do anything with the units at all, need
to throw around parse trees (e.g.: unifying values in different units
from two different tables).  The less flamboyant the things they have
to expect are the better.

True, a parser library can help providing a unified interface here,
but if we can keep the standard so simple that almost any kind of
parser library will do the trick, even better, no?

That some services may have to rework their units seems, in
comparison, a small price to pay, even more so since they only have
to write and run the conversion software once (as opposed to VOTable
clients having to understand all kinds of syntaxes everytime they
parse a unit, in every VOTable library).

Similarly, I'd doubt a sensible spec will ever provide a "least
surprise" -- people will always expect something that's not in the
spec.  Let's rather have something clear that's easy to learn and
lets parsers easily give expressive error messages (which becomes
harder when more different strings are valid expressions).

> I'm sure the discussion would benefit from more voices, either
> there or on this list.  I mention it here only because the wiki
> doesn't generate alerts for edits, so this may have dropped off
> some people's radar.
+1 from me.  

At this stage, I guess the difference between the "minimal"
grammar and the "lenient" grammar are not huge, so a decision
doesn't mess anything up badly in either direction.  Deciding to go
for minimal might help ward off later requests for additional
features, though.  Deciding to go for lenient might, on the other
hand, make for a more relaxed RFC...

Cheers,

           Markus