A modest proposal for VOEvent

[Bob Denny]

Rick Hessman:
> I believe the thing to avoid is
> 
> 	<orbitalElements q="1.2345" P="9.54321" Punits="days" ...   />
> 
> as too compact and illegible...

and the values cannot be validated by a schema-driven parser. I agree that this
is the wrong way to go!

> ... and
> 	<orbitalElements>
> 		<q>
> 			<units>none</units>
> 			<value>1.2345</value>
> 			...
> 		</q>
> 		...
> 	</orbitalElements>
> 
> as too verbose and cumbersome to parse.

Also agreed. It's the opposite end of the spectrum and just as bad.

> The only reasonable system
> is to use attributes for secondary information, e.g.
> 
> 	<orbitalElements>
> 		<q units="none">1.2345</q>
> 		<P units="days">9.54321</P>
> 	</orbitalElements>
> 
> but then, everyone has their own tastes (and those tastes even change).

I'm a KISS Principle guy. The MPC has standard formats for numbered asteroid and
cometary elements already, the so-called "1-line" format(s). Everyone knows what
these are, how they are formatted, and what units they are in. They've been
around for many years. MP versus cometary can be determined by inspection. So
something as simple as

   <orbitalElements>K01FI5V  7.7   0.15 K014L   0.10308 ...</orbitalElements>
   <orbitalElements>    PJ97T030  1998 03  9.3751  ...</orbitalElements>

would carry everything there is to know about the elements. If only the number
or designator is given, that could automatically reference the MPC's orbital
elements database. That would provide the "latest" elements if that were
preferable (maybe you want to specify the elements that WERE used and not the
elements TO use). So

   <orbitalElements>K01FI5V</orbitalElements>
   <orbitalElements>0029P</orbitalElements>

Now what about NEOs which have only a rough short-arc orbit, and for which there
are no elements available? I've successfully used the MPC's "NEOCP Ephemeris"
format. Needless to say, the position of an NEO is not well known very far
ahead, so this would apply only to timely observations in response to a VOEvent.
In that case, some ephemeris lines covering the expected validity period of the
event, spaced an hour or two apart, should be "good enough". One can do
something like a Lagrange interpolation over that data and get a pretty good
position. So something like

   <ephemeris name="A123456789">
      <pos>2004 10 27 02    01.6915    -40.095</pos>
      <pos>2004 10 27 03    01.6834    -40.167</pos>
      ...
   <ephemeris>

  -- Bob