VOEvent working draft published: version, param

[Matthew Graham]

Tony Linde wrote:

>Hi Rob,
>
>  
>
>>Providing a general purpose mechanism for grouping and typing 
>>keyword=value pairs using <Param> is precisely the key 
>>compromise that will bring VOEvent to life.  Other VO 
>>    
>>
>
>It is the use of <param> that will kill VOEvent before it even has a chance
>to live. To produce an approach which guarantees that receiving applications
>will fail is not going to engender any confidence in the IVOA's ability to
>produce standards that are consistent with the real world.
>
>The only way you can avoid the guarantee of failure is by wrapping the
>definition of the <param> in so many ifs and buts about who can create names
>and what they must look like that the spec will make the EU constitution
>look simple and easy to use.
>
>  
>
>>facility suggested for VOConcept.  And in particular, we do 
>>not have the time to wait for schemata to be developed for 
>>all possible instrumentation and observing modes that may 
>>generate sky transient alerts.  I fear that you underestimate 
>>the sheer terror of the thought of trying to fully 
>>characterize the behavior of even a simple astronomical 
>>instrument.  And each new instrument becomes more-and-more 
>>clever and more-and-more complex.
>>    
>>
>
>I've no idea what VOConcept is. And you do not have to wait for schemata of
>any sort. It takes less time to create a private schema and use it in your
>own VOEvent record than it does to code up all the name-value string pairs
>in your transmitting applications. And hugely less time for the receiving
>applications.
>
>No-one is asking for the whole behaviour of the instrument to be
>characterized. In the same time it takes a person to dream up the names for
>the name-value pairs, you can create a schema the same way. And then you
>save a lot more time coding up your sending application.
>
>  
>
>>experienced "writers of transmitting server software and 
>>receiving applications" who I expect would be least receptive 
>>at this point of backpedaling toward a VOEvent specification 
>>that requires an explicit new extension schema be written for 
>>each instrument supported.
>>    
>>
>
>Are you really telling me that your highly experienced developers, who have
>probably spent years creating complex software, are incapable of stringing
>together a few elements into an xml schema? Even I can do that! I would
>think they'd be more frustrated at the likelihood of their data being
>misread and misinterpreted because we've taken a short-cut to the distant
>past and embedded xml-ised CSVs into the spec they're forced to adhere to.
>
>  
>
>>The issue is precisely how to balance elegance of expression (words  
>>like "cleanest") with elegance of process (words like "quickest").   
>>    
>>
>
>There is no issue of balance. With schema extensions you get both, with
><param> you get neither.
>
>
>Roy referred to the fact that <param> appears in the VOTable spec. I'm happy
>to admit that VOTable has worked under the initial circumstances of the
>early VObs efforts. It works simply because it is always at the end of a
>chain: all the interpreting is done by people. But VOTable always fails when
>it is sent from one application to another. We've hit just that problem with
>the workflows in AstroGrid: since none of the information (like <param>
>name-value pairs) is formally defined, it cannot be formally interpreted by
>an application - it always takes a human to do the interpreting.
>
>If you are saying that VOEvent records are *never* going to be sent to
>applications for interpreting and actioning and that they will only ever be
>sent to humans (or to tools which will only be used directly by humans like
>the VOTable tools) then <param> might be used (but will still take more work
>than extension schemas). But if you expect a VOEvent record to ever be
>interpreted by software which will kick off another action, like directing a
>telescope or running a data search, without direct human intervention, then
><param> is simply not suitable.
>
>Cheers,
>Tony. 
>
>  
>
>>-----Original Message-----
>>From: Rob Seaman [mailto:seaman at noao.edu] 
>>Sent: 24 June 2005 20:57
>>To: Tony Linde
>>Cc: voevent at ivoa.net
>>Subject: Re: VOEvent working draft published: version, param
>>...
>>    
>>
>
>  
>
Hi,

Let's assume that the VOEvent schema has something like:

<xs:element name="Group" type="voe:GroupType"/>

<xs:complexType name="GroupType">
  <xs:sequence>
    <xs:element name="Param" type="voe:ParamType" minOccurs="0" 
maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:attribute name="type" type="xs:string"/>
</xs:complexType>

<xs:complexType name="ParamType">
  <xs:attribute name="name" type="xs:string"/> 
  <xs:attribute name="value" type="xs:string"/>
  <xs:attribute name="unit" type="xs:string"/>
  <xs:attribute name="ucd" type="xs:string"/>
</xs:complexType>

which will happily validate:

<Group type="GRB_INTEN">

      <Param name="cnts" value="73288" unit="ct" ucd="phot.count" />
      <Param name="peak" value="1310" unit="ct/s"
      ucd="arith.rate;phot.count" />

</Group>
/
/Now there is nothing to stop me defining an extension:

<xs:complexType name="GRB_INTEN">
  <xs:complexContent>
    <xs:restriction base="voe:GroupType">
      <xs:sequence>
        <xs:element name="Param" type="voe:GRB_INTEN_PARAM" minOccurs="0"/>
      </xs:sequence>
   </xs:restriction>
  </xs:complexContent>
</xs:complexType>

<xs:complexType name="GRB_INTEN_PARAM">
  <xs:complexContent>
    <xs:restriction base="voe:ParamType">
      <xs:attribute name="name">
        <xs:simpleType>
          <xs:restriction base="xs:string">
             <xs:enumeration value="cnts"/>
             <xs:enemeration value="peak"/>
          </xs:restriction>
        </xs:simpleType>
      <xs:attribute>
      <xs:attribute name="value">
        <xs:simpleType>
          <xs:restriction base="xs:string">
             <xs:pattern value="\d*"/>
          </xs:restriction>
        </xs:simpleType>
      <xs:attribute>
      <xs:attribute name="unit">
        <xs:simpleType>
          <xs:restriction base="xs:string">
             <xs:enumeration value="ct"/>
             <xs:enemeration value="ct/s"/>
          </xs:restriction>
        </xs:simpleType>
      <xs:attribute>
      <xs:attribute name="ucd">
        <xs:simpleType>
          <xs:restriction base="xs:string">
             <xs:enumeration value="phot.count"/>
             <xs:enemeration value="arist.rate;phot.count"/>
          </xs:restriction>
        </xs:simpleType>
      <xs:attribute>
    </xs:restriction>
  </xs:complexContent>
</xs:complexType>

and then doing:

<Group type="GRB_INTEN" xsi:type="GRB_INTEN">

      <Param name="cnts" value="73288" unit="ct" ucd="phot.count" />
      <Param name="peak" value="1310" unit="ct/s"
      ucd="arith.rate;phot.count" />

</Group>
/
/and now it is formally defined and strongly typed.

    Cheers,

    Matthew