action items

[Matthew Graham]

Hi,

These points raise a matter that needs to be discussed by the group.

On Sep 28, 2009, at 10:49 AM, Roy Williams wrote:
>
>>> (5) What can be done about searching on string parameters? Strict  
>>> equality? Contains? Startswith, Endswith?
>>
>> The current behaviour is strict equality and case sensitivity (so  
>> seap.param = Ast1 matches 'Ast1' but not 'ast1'). We could broaden  
>> this to include something akin to the '%' in SQL queries, e.g.
>>
>> seap.param = %st%
>>
>> which would meet your contains, startswith and endswith. Anything  
>> more than this, though, should go in the CEAP (Complex Event Access  
>> Protocol).
>>
>>> (6) I am assuming that a "dataType" attribute will appear in the  
>>> VOEvent2.0 spec, so that we know whether something is a number or  
>>> a string. For strings "19" < "2" but for floats 19 > 2.
>>
>> The current version of SEAP is based around VOEvent 1.1. I would  
>> anticipate a SEAP 2.0 to deal with queries against the VOEvent 2.0  
>> data model.
>
> In answer to both (5) and (6), the problem with VOEvent 1.1 is that  
> all parameters are strings, because there is no dataType attribute  
> in the Param definition. So if the values of two parameters are "2"  
> and "19", we cannot tell if they should be converted to floats (2 <  
> 19) or not ("2" > "19").

Given that VOEvent 1.1 has no data typing and there is a requirement  
to support range queries in SEAP (e.g. 16 < mag1 < 20), how do we  
overcome the mismatch? I can see three (not mutually exclusive)  
alternatives:

(1) Rely on implementor knowledge: The SEAP server 'knows' that mag1  
takes numerical values and so will parse and convert any range queries  
appropriately. At the worst it can construct a standard SQL string to  
send against the DB, catch the error when this fails because of data  
type mismatch and return a HTTP 500.

(2) Information about the data dictionary that the VOEvent stream uses  
in its <What> section is registered in a registry. This includes  
details about the data type and so the SEAP service can poll the  
registry to do its data type checking.

(3) SEAP is only defined to run against VOEvent 2.0 where we have data  
type information (maybe).

What do you all think?

	Cheers,

	Matthew