VOEvent working draft published: version, param

[Alasdair Allan]

Tony,

A slightly more reasoned response, with apologies for my rather abrupt
message earlier, you caught me at a bad time...

> As I said before, my argument is less with the typing (not even sure what
> the argument there is) than with the need to ensure that the names of
> elements can be unambiguously interpreted by downstream software.

Okay, I'm not clear what your arguement is then because all of these
<Param> tags have a ucd="" atrribute and a units="" attribute. You know
what it is, and what units it's in? The field itself is loosely typed (it
might be a float or a double), but that isn't (apprently) the issue?

However...

The current VOEvent draft is a very careful compromise between the various
parties involved, one of the most vital things for the robotic telescope
community is rapid follow up. If you want to slew several tons of telescope
around the sky, you can't sit around and wait for 10 seconds while some
software parses a lengthly XML message. 

Rapid parsing is amongst the top priorities, and ambiguity of some of the
frilly bits and pieces around the edge are not necessarily something we're 
going to be able to to worry about. 

If you really want to exactly specify (arbitarily) complex information
then that (amongst other uses) is what the <Reference> tag is for, leaving
that sort of stuff off board, rather than in the VOEvent packet itself.

For instance the instrument specification, and the descirption of how the
observations were made, are almost entirely off board in a remote RTML
document. If there is any information in the first place!

Parsing XML is slow, sending XML over SOAP (especially over HTTP) is very
slow. This is a comunity that is used to 40 network ordered longs as a
packet format over already established raw TCP/IP connections. Speed is an
issue, hanging namespaces and extended schemas off the packet isn't going
to be acceptable because it will impact performance to a significant
enough degree that the standard will become unusable for its prime use
case, rapid transient followup.

>From running some speed test it already appears that I'm going to have to 
shave some corners when trying to parse some of the more complex bits of 
the standard. Make assumptions in other words...

It's also probable that, at least at the sharp end of things, that I'm
going to have to dispense with the niceties of web and grid services. It
looks like I might be reuced to pushing these XML documents around via raw
TCP/IP. The handshaking time for a SOAP service is increasingly looking to
be too mcuh overhead to be worth the effort.

As you might imaging, to someone trying to shave 1/2 a second off the 
loopback time on a VOEvent packet so that the data reduction pipeline can 
keep up with the instrument in real time, any suggestion of making the 
standard more complex is somewhat unwelcome.

Al.