VOEvent working draft published: version, param

[Roy Williams]

>>> 3.3.1 <param>

The question here is one of weak and strong typing. The current VOEvent 
draft advocates weak typing, by using an arbitrary set of <Param> 
elements, whereas Tony is suggesting a strong typing approach by using 
an extension schema.

The <Param> element is a lot like a FITS keyword.  A name and a value.  
The value is a string and the receiver is supposed to somehow know what 
is integer and what is float. In a FITS header, I can say "COUNT = 
-200" or "COUNT = 3.141", even though a negative or float value of 
COUNT might well be meaningless.  Also there can be name collisions. 
There is no formal mechanism to look up the meaning of a name. It is 
the wild frontier and anything goes!

By contrast, the strong-typing approach treats everything as an object, 
with inheritance, typing, validation rules, etc. It is more complicated 
to setup, but more extensible and more amenable to computer-computer 
data exchange. Strong typing means a formal data model, the idea of 
deciding exactly what is going on before writing any code or prototype.

But I maintain we cannot do strong typing right now. In VOEvent, we do 
not yet know the content of the <What> element that describes what has 
been seen. We (OK I mean me) have not made the pipeline that generates 
the events. We are not in a position to make data models of the 
observed quantities. Therefore we *cannot* effectively do the 
strong-typing approach, and we must slither along with these slippery 
weak-typed parameters and hope to clarify things once the collaboration 
is mature.

Now comes the typed <Group> element. It is the magic train that will 
take us to strong typing (if we want to go there).  VOEvent allows a 
group of Params to be put in a <Group> element and given a type, for 
example we might define a type called MyBrightness as a combination of 
magnitude, filter name, and error estimate.  It would be used by 
agreement between a small number of people that exchange events.  But 
then suppose MyBrightness becomes popular, and we want to integrate it 
in a strongly-typed way. That is simple now. In XML-speak, we make a 
tiny change, from:
<Group type="MyBrightness"> to <Group xsi:type="MyBrightness">
The latter is now genuinely strongly typed -- it implies an object 
called MyBrightness that inherits from an object called Group. The 
MyBrightness type is defined in a schema, validated, etc etc.

So you see, Tony, there is a method in this sloppiness of weak typing. 
We let people experiment and build prototypes without any rigour,  but 
move small step by small step to the rigour of a strongly-typed data 
model when, and only when, they feel the need to do so.

Roy

California Institute of Technology
626 395 3670
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2863 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20050624/45fcdd62/attachment-0001.bin>