ObsTAPdraftDiscussionEmMinMax < IVOA

In the current !ObsTAP proposal, =em_min= and =em_max= are nullable. What does that mean when any of them is NULL? If the service is registered, and specifies the corresponding bands in the VO Registry, it should use the bounds of those bands as =em_min= and =em_max= for all the collection, unless it can provide better bounding.

Therefore, I propose that =em_min= and =em_max= *must not* be NULL.

-- IVOA.JuanDeDiosSantanderVela - 07 Mar 2011

<hr>

This is the same "approximate" value (or worse, "dummy" value) vs admitting lack of information (NULL) debate we have had for most columns. I prefer to <b>allow NULL</b> and not force people to approximate.

The spectral coverage in the registry could be a pretty poor estimate if the service aggregates content from multiple sources (eg at CADC we have everything from radio to far UV). I think it is the case that these may be genuinely unknown or hard to get values for raw data in non-standard formats (calib_level 0), but implementors still want to include both raw and calibrated data in the ObsCore service.

In general, NULL behaves the right way in the where clause: if you care about the energy, you put a numeric condition on the em_min and em_max fields and you don't find data where it is NULL. If the user wants to be lenient, they can add <em>OR em_min IS NULL</em>. The important thing is that the user can tell which results have known energy bounds and which do not.

-- IVOA.PatrickDowler - 2011-03-23


<br/>
<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->

This topic: IVOA > WebHome > IvoaDataModel > ObsDMCoreComponents > ObsTAPdraftDiscussion > ObsTAPdraftDiscussionEmMinMax
Topic revision: r2 - 2011-03-23 - PatrickDowler