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

Thanks for the input, Pat. Then, I think we should make it explicit in the document, to make sure that the intent of the NULL is clear. In fact, that was really my objection: making clear what is implied.

As for the registry, then, I think that's where the approximation takes place… and in the CADC case you just offer pan-chromatic coverage, but not all of the datasets have em_min and em_max. I can buy into that.

-- JuanDeDiosSantanderVela - 24 Mar 2011