GRBs retractions - Param or value?

[Petr Kubanek]

Thinking about Param/structure aproach I come with that: if you know GCN
network, you noticed that sometimes retraction for GRB is issued. That's
due to various reasons, sometimes it's ommision of possible know
gamma-ray source from blacklisting, sometimes it's due to lost of star
tracker position and hence detection of know source at wrong location,
sometimes it's particle hitting detector. Look to GCN archive for
examples. And those messages arrive even by GCN socket connection, so
are machine readable.

GCN also issues GRB-type messages for know sources, which are ussually
not interesting for GRB hunters - they are message saying that some know
source have brightened (SGR, AGN..).

If you use Param approach, you will of course will be able to map it -
using some boolean value, saying if that's still valid event, and then
in description add comment that it was particle hit. So it will look like:

<Param name="IS_GRB" value="false" ucd="obs.isvalid"/>

Or you will add attribute to data, so:

<grb>
  <type>RETRACTION</type>
  <reason>particle hit</reason>
</grb>

Using Param approach, you will hide very important parameter (if that
event is real GRB or only know source) into UCD parameters. And if poor
programmer neglect that important UCD parameter (because they are 100s
of UCDs and by nature are not structured and nowhere is specified which
parameters should arrive with particular VOEvent entry), he will get at
least one fake response to event which is not interesting at all.

Now compare it with structured GRB approach. What is better? Having it
hidden somewhere among UCDs, or saying that is GRB attribute and will be
at every GRB (or declared by obligatory type field or whatever, which
will be documented at XML Schema).

Of course you might create map mapping Params to VOEvent messages, but
that way you are actually duplicating purpose of XMLSchema by developing
own meta-schema..similar to approach: we don't like XML schemas, so we
will develop better ones. Thousands designers had tried that, and I
haven't heard of any one developing anything better - only things
similar to XML emerged and then disapeared, as they were not used.

By using Param fields you also miss one important advantage of XML,
which you cannot see when you try to parse XML in human mind - from
schema, you can build object model (of GCN noticess..), Java Beans for
easy data manimupaltion, databases which will store VOEvents in
relational database. You cannot build it (or it will be very incomplete)
from Param loosely-coupled attributes.

Petr