VOUnits: _another_ version, based on implementation feedback

[Arnold Rots]

A couple of comments.

I strongly support using "UNKNOWN", rather than '?'.
It's consistent with usage in STC.

I agree that STRING QUOTED_STRING is ugly, unwise, and not really necessary.

I agree with Markus on the function names.

And I agree that deca/deka should be disallowed - it's pretty useless
anyway.

I do lament disallowing "cy": it's common and clear, and I'm not impressed
by "hyr", even less by "ha".

MJD is a concept; more importantly, it serves to set the zero point
of the time measurement and implies use of the unit 'd'.
So, yes, it definitely is not a unit; the same for JD, of course.

I am not entirely comfortable with disallowing "Ba" and "ta"
(although I am about equally uncomfortable with allowing them).
The question is: what do you propose to do when someone asks
for putting a catalog that measures time in one of thsoe units into a
VOTable?

Just for a piece of trivia:
There is a body of data files that uses a "Vanguard unit of time" which
actually is a centi-day
- but the centi-day is disallowed.

Cheers,

  - Arnold

-------------------------------------------------------------------------------------------------------------
Arnold H. Rots                                          Chandra X-ray
Science Center
Smithsonian Astrophysical Observatory                   tel:  +1 617 496
7701
60 Garden Street, MS 67                                      fax:  +1 617
495 7356
Cambridge, MA 02138
arots at cfa.harvard.edu
USA
http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------------------------------------------



On Mon, Oct 28, 2013 at 5:46 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Dear Semantics WG,
>
> Let me first thank Norman for doing the heavy lifting on this.
> VOUnits has become a really useful document by now.
>
> Having said that, I'd like to point at some issues that I'd like to
> draw attention to -- I'm fine with all but one of them, but I think
> the decision to leave them as they are needs to be passed conciously.
>
> On Fri, Oct 25, 2013 at 06:29:22PM +0100, Norman Gray wrote:
> > Markus has a couple of other suggestions or issues which I didn't
> > feel able to take an independent decision on; I'll let him raise
> > those if he feels so inclined.
>
> So, here goes:
>
> ...
>
> >>>>>>>>> Atomic units
>
> On p. 32, it says:
>
>   STRING   a non-empty sequence of letters [a-zA-Z]+
>
> STRING, to save you the lookup, is used for both "atomic" units and
> function names.  I'm fine with this, but note that it excludes the
> underscore (so, no M_Jup with this).  Please protest now if you want
> underscores.  Me, I can live without, and maybe it's a good idea to
> reserve it for future use.
>
> I also see a slight contradiction with Table 6 that offers a "?" as a
> placeholder for unknown units.
>
> This contradiction is resolved right now by stipulating that some
> higher processing level should be removing ? before passing things on
> to the VOUnits processor.  This is probably the least
> specification-intensive way of resolving the contradiction, but it
> also goes quite a bit against my sense of specification aesthetics.
>
> A simple alternative could be to let
>
>   STRING -> [A-Za-z]+|\?
>
> An alternative I'd like it even better would be to ditch the question
> mark altogether and just say
>
>   Unit authors SHOULD write "unknown" when a quantitiy is known to
>   have a unit but that unit cannot be determined.
>
> This would work just fine with the way we're specifying units right
> now.
>
> But again, I can live with what's there.
>
>
>
> >>>>>>>> SI prefixes on unknown units
>
> The unit production on p. 39 allows
>
>   unit: STRING QUOTED_STRING
>
> which is there to allow prefixes on quoted units, like
> M'jupiterMass'.  I'm fairly opposed to that; as Norman writes in
> 2.12.1, "this is not often likely to be a good idea," and I could
> find stronger language about it.
>
> Does *anyone* actually want this?  If yes, so be it, but if not,
> let's not do it.  It complicates the already ungraceful quoted units
> business even more.
>
>
>
> >>>>>>>>> Quoted function names
>
> The VOUnits grammar on p. 39 has this:
>
>   function_application: STRING OPEN_P complete_expression CLOSE_P
>     | QUOTED_STRING OPEN_P complete_expression CLOSE_P
>
> This is the only place at which I'd *really* like to see a change --
> allowing quoted strings as function names is an IMHO unnecessary
> complication.  Quoted strings were introduced to avoid the expansion
> of SI prefixes, and of course SI prefixes are not allowed for
> function names anyway.
>
> The point for quoted function names then appears to be that authors
> may want to use known units as function names, as in 'km'(adu/s);
> however, that is not actually required, as the km in km(adu/s), by
> the grammar, must be a function name anyway.
>
> Whether it's a good idea to allow arbitrary function names is of
> course yet another matter.  Do we really want km(adu/s) and
> km.(adu/s) both be well-formed but having a completely different
> semantics?  Shouldn't log, ln, exp, and sqrt be good enough for
> anyone?
>
> That aside: I'd really, really like see quoted function names go
> away.
>
>
> Finally, from the latest changes,
>
> >>>>>>> The deka situation
>
> > \item Clarified that the ambiguity in \unit{dadu} should remain
> >     unresolved, and the correct behaviour unspecified (is it
> >     deci-\texttt{adu} or deka-\texttt{du}?).
>
> Ouch.  It always hurts to have to keep something unspecified, but in
> the presence of unknown units it's *really* hard to prescribe
> sensible behaviour here.  What a mess.  I really, really wish whoever
> came up with the "da" prefix (the only two-letter SI prefix) hadn't
> done so.
>
> May I suggest to change:
>
>   We can think of no cases where the ambiguity is plausible enough
>   that resolving it is worth the specification effort, so we deem the
>   parse of da.* to be unspecified.
>
> to:
>
>   In the light of this ambiguitiy, we leave the parse of da.*
>   unspecified.  This means that unit authors SHOULD not apply the
>   deci-prefix to units starting with a and not apply the deka-prefix
>   at all.
>
> I'm sure a lot of Austrians will hate me for that -- when I was last
> there, people would ask for "10 deka[sc. gram] of that Tiroler goat
> cheese" --, but maybe this affront could be an incentive for an
> Austrian contribution to the VO.
>
> Cheers,
>
>           Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/semantics/attachments/20131028/cde6cf0c/attachment.html>