VOEvent working draft published: version, param

[Tony Linde]

> sky, you can't sit around and wait for 10 seconds while some 
> software parses a lengthly XML message. 

Now this is the bit of your argument I don't get, Al. are you really saying
that it takes less time to act upon: 
  <param name="ActionItem" value="HoistTheMainsail" ucd="ship.sail.action"
/>
than:
  <shipns:ActionItem>
    HoistTheMainsail
  </shipns:ActionItem>
or, if you want to keep the weak typing:
  <shipns:ActionItem value="HoistTheMainsail" />
?

Sorry, I don't buy that. In the case of the <param> you need to find all the
<param> elements during the record parsing, match the names against your
internal lookup table of names you understand and then act upon them, while
with the simple element inclusion the action is fired when the record
parsing hits the recognised element. The latter has to be significantly
faster.

> sending XML over SOAP (especially over 
> HTTP) is very slow. 

Using named elements instead of strings in <param>s will have no effect on
the sending speed afaics. In fact it ought to be faster because it is
shorter: explicitly named elements do not require UCDs to accompany them in
the record.

> time, any suggestion of making the standard more complex is 

I am arguing to make the standard simpler: the <param> element makes for
ambiguity and so makes handling it more complex. Just because the length of
the standard document is shorter does not mean it is simpler: usually the
opposite.

Cheers,
Tony. 

> -----Original Message-----
> From: Alasdair Allan [mailto:aa at astro.ex.ac.uk] 
> Sent: 25 June 2005 10:40
> To: Tony Linde
> Cc: 'IVOA VOEvent List'
> Subject: RE: VOEvent working draft published: version, param
> 
> 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.
> 
>