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.

-- JuanDeDiosSantanderVela - 07 Mar 2011


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 allow NULL 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 OR em_min IS NULL. The important thing is that the user can tell which results have known energy bounds and which do not.

-- PatrickDowler - 2011-03-23


Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r2 - 2011-03-23 - PatrickDowler
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback