action items

[Matthew Graham]

Hi,

On Sep 28, 2009, at 11:25 AM, Rob Seaman wrote:

> Matthew Graham wrote:
>
>> 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).
>
> #1 is what we have now.  It is not sufficient.  #3 is desirable,  
> perhaps necessary, but also insufficient - whatever the protocol  
> allows, we are unlikely to win consensus to force data types be  
> present for conformance.  Thirty years in, FITS headers are still  
> seeing numerical keywords expressed as strings.  It simply can't be  
> illegal to say "19" as a string.
>
> Rather, I think SEAP is a good tool to drive forward improvements to  
> VOEvent's ties to the registry.  Either we use XML schema (or  
> whatever comes after the current flawed schema) in all their gory  
> detail, or we have to provide some alternate mechanism for  
> distributing knowledge of the semantics of different authors/ 
> publishers' use of params.  If not the registry, then what?
>
> We should discuss the best way to drive VOEvent v2.0, SEAP and  
> registry-based VOEventStreams forward.  If they are tied together,  
> which has to happen first?  Who will commit to deploying  
> infrastructure conformant to all three?  Etc.  I don't believe it is  
> any more trouble to wrap this all up with a pretty bow, we simply  
> have to lay out the steps to get there.
>
> Rob

With Roy's assistance, I pretty much fleshed out the schema last year  
for registering VOEvent streams and services. One of the things that  
we were waiting for were the SEAP details. I therefore suggest the  
following:

(1) Couple SEAP and the VOEventService registry extension together in  
terms of standards scheduling

(2) Add text to the SEAP document describing this issue and the  
"solutions".

Do we need to do anymore that this?

	Cheers,

	Matthew