VOEvent - Param comment

Petr Kubanek Petr.Kubanek at obs.unige.ch
Mon Aug 7 08:58:06 PDT 2006


>>> <GRB>
>>>   <trigger_num>114299</trigger_num>
>>>   <rate_signif>20.49</rate_signif>
>>>   <grb_inten>73288</grb_intent>
>>> </GRB>
> 
> 
> This doesn't meet the design goals, see below...
> 
>> The difference here is between what I call a generic container and a
>> semantic container.  The latter is helpful when the scope of  meaning is
>> well contained.
> 
> 
> The later is useful if you know the contents the message will carry,  
> the <Param> element was designed the way it was precisely because we  
> have absolutely no idea the semantic content that the message will  have 
> to carry. If you look at, for instance, OGLE and GCN messages,  the 
> <Param> elements carry totally different things. That's why it  has a 
> ucd="" attribute to provide the semantic meaning that you seem  to want.

That's where choice element came in. You can define parameters for GCN and for OGLE using it. Schema will look like (that's most probably not valid, it's only for reference):

<xs:complexType name="grb">
  <xs:sequence>
    <xs:simpleType name="trigger_num" base="xs:positiveInteger"/>
    etc..
  </xs:sequence>
</xs:complexType>

<xs:complexType name="ogle">
  <xs:sequence>
     <xs:simpleType name="trigger_id" base="xs:positiveInteger"/>
     etc..
  </xs:sequence>
</xs:complexType>

<xs:choice minOccurs="0" maxOccurs="1">
  <xs:complexType name="GRB" extends="grb"/>
  <xs:complexType name="OGLE" extends="ogle"/>
</xs:choice>

So the XML can then look like:

<GRB>
  <trigger_num>1234</trigger_num>
  ..etc
</GRB>

or

<OGLE>
  <trigger_id>345</trigger_id>
</OGLE>

but of course cannot contain both types.

This approach of course cost more time to document all possible events, but that extra time spend on design will pay back on developer time when they will try to understand author intend. Schema is only one, there will be more developers who will try to understand it and use it - so you save some time when you make solid specifications, not loosely-coupled param fields.

I can put together recomendations for GCNs, so I'll get proof it's possible to do it - if you want to see it. Due to nature of GCN and multiple satellites and multiple event types per satellite it will not be easy, but I think it's worthy to do it.

Petr



More information about the voevent mailing list