A modest proposal for VOEvent

[Bob Denny]

Should orbital elements be a WhereWhen and not a What? Elements combined with a
Time give a Position, thus a WhereWhen? I'm not clear on the *role* of orbital
elements in a VOEvent message, so maybe I'm off here? If they are critical, then
their form(s) should be constrained and not expressed in What (which is after
all unconstrained).

As always, I'd like to see units go away in constrained data. If the orbital
elements are of some type, then everyone should know not only what the
parameters that make up that type of elements are, but also that each of the
parameters always has the same units.

Consider a VOEvent message as a one-to-many thing. Why require the many (the
receivers) to provide every conceivable/allowable conversion? One conversion
(maybe) at the sending end (the "one") takes care of it. Everyone knows what
units to expect for each bit of data. Then the receiver only needs to make
specific conversions needed internally by its logic and maybe that's no
conversion at all!

In the (unconstrained) What section, though, of course units are needed! And
Roy, I finally get it with dataType - but probably for a different reason than
you proposed it :-) A Param needs both units and dataType.

Anyway, to address the validation and expression of What (and yes I am getting
to dataType!): <What> /can/ be validated as to its structure, and turned into an
object model. But each Param is a 'blob' with unconstrained properties and no
value (it's not <param x="a" b="y">value</param>, at least not now). Yet it
allows unlimited expression. So it's a tradeoff.

What if we used the SCHEMA data types rather than types from VO vocabulary or
some other set of types? In principle, this would allow a known Param to be
validated by XML/schema. If the Param is known, a mini-schema could be
constructed for that Param. Pluck the Param out of the message XML and make a
separate XML message out of it, referencing the mini-schema. Feed that into the
XML engine and you have validation because the data type is a schema data type.
This principle could be applied to entire Groups too. I know it sounds weird...
but I can see some sort of plug-in architecture for "known" Params and Groups.
This creates a new vocabulary. Is this ridiculous (it might be!). But it's an
idea...

  -- Bob