VOUnits RFC

[Frederic V. Hessman]

I would also like to see a more formalized grammar in the document, also pointing in future directions, rather than the collage of previous and future standards (with lots of empty table boxes).   This is what a real VO programmer is going to need and the grammer might even be useful as input to some grammar parser (I used to understand yacc grammars, but it's been decades, so please excuse my non-formal syntax).   Just having a bunch of tables is ok, but it's hard to distill a standard from them.

How about something along these lines (I'm sure someone can do this much better, but you'll get the jist …)? In my grammar, the plus sign is simple concatenation unless in quotes.  I purposefully haven't split things up into SI and non-SI, astronomical and non-astronomical, since the parser doesn't care and just needs to know what to consider.  One simply has to say that formal SI units are preferred.

unit
	: complex_unit
	| factor+complex_unit				(numerical pre-factor and unit understood as multiplication; e.g. "10^3 kpc")
	| complex_unit+'/'+factor			(numerical post-factor understood as simple division; e.g. "/100")
	| factor+'/'+complex_unit			(e.g. wavenumber in '1/kpc')
	| …						(etc)

factor
	: number
	| function+'('+number+')'			(e.g."sqrt(pi)")
	| number '**' number				(e.g. "pi**2")
	| number '^' number				(same as "**")

function
	: 'sqrt'
	| 'sin'
	| 'cos'
	| …						(etc, for all the others)

number
	: '-'+number					(negative number)
	| '+'+number					(positive number)
	| integer					(usual definition)
	| {however one says something like "1.23456e+78 and its different forms and sub-forms etc.}
	| 'pi'

complex_unit
	: std_unit
	| other_unit
	| function+'('+complex_unit+')'
	| complex_unit+'.'+complex_unit			(multiplication for historical compatibility)
	| complex_unit+'/'+complex_unit			(division, with math priority)
	| std_unit+'-'+integer				(e.g. "m-2" for "1/m**2" for historical compatibility)
	| std_unit+'+'+integer				(e.g. "m+2" for "m**2" for historical compatibility)
	| …						(etc)

std_unit
	: std_prefix+std_base
	| std_base

std_prefix
	: 'm'						(milli-)
	| 'k'						(kilo-)
	| 'u'						(micro-)
	| 'M'						(mega-)
	| 'h'						(hecto-)
	| …						(etc, for all the other standard prefixes)

std_base						(things one SHOULD be able to parse)
	: 'm'						(meter)
	| 's'						(second)
	| 'V'						(volt)
	| 'g'						(gram)
	| 'as'						(arcsecond)
	| 'a'						(year)
	| 'eV'						(electron-volt)
	| 'pc'						(parsec)
	| 'B'						(byte)
	| 'Pa'						(Pascal)
	| …						(etc for all the other "standard" units one should know and love)

other_unit						(things one MIGHT be able to parse or look up)
	: std_prefix+other_unit				(e.g. 'Mlbs' for "megapounds", if one is so inclined)
	| string+'_'+string				(e.g. 'M_Jupiter', which obviously isn't "Mega"+"_Jupiter" if one doesn't know what "_Jupiter" means)
	| string					(e.g. 'jupMass') 

….

etc.   One could probably define a "fits_unit" etc as a subset to make compatibility easier.   No, I haven't gone through all the examples in the VOUnits document….

Yes, the formal allowance of pre-factors and post-factors is non-standard, but as long as we say so, that's ok: either one is modern (all new VO tools) or one is old-fashioned (FITS).

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/semantics/attachments/20130729/b448e8a6/attachment.html>