obscore 1.1 - small issues

[alberto micol]

Dear Mireille,

I need to complement Sonia’s and Marco’s feedback with a very similar issue
for the following fields, all declared as optional (with a MAN = NO) in the TABLE 5
but all having ‘principle’ set to 1 in TABLE 6:

ObsCore field name        principle
------------------- -------
dataproduct_subtype 1 
o_calib_status      1 
obs_creator_name    1 
obs_release_date    1  
obs_title           1  
s_pixel_scale       1  
target_class        1 
obs_creation_date   1 
publisher_id        1 
s_ucd               1  
s_unit              1  
s_resolution_max    1  
s_resolution_min    1  
em_ucd              1 
em_res_power_max    1  
em_res_power_min    1  
em_resolution       1  
o_unit              1

Should not the principle field be set to 0 for all optional fields?

Many thanks,
Alberto


> On 22 Aug 2017, at 11:24, Mireille Louys <mireille.louys at unistra.fr> wrote:
> 
> Hi Sonia & Marco, Hi all, 
> 
> Thanks for your feedback in this precise implementation of the Obscore 1.1 specification. 
> 
> Apologies for these typos and  missing descriptions terms that went through our vigilance as authors and editors.  
> We are aware that when a model offers many fields, many implementations are needed to test all the fields precisely and extensively.
> 
> I have not experienced the errata process yet, but it seems appropriate here.
> 
> Cheers , Mireille.
> 
> 
> 
> Le 22/08/2017 à 10:29, Marco Molinaro a écrit :
>> Dear DM,
>> working on ObsCore-1.1 in the development of a tool to try to help administering that table we found a few discrepancies in the REC text.
>> 
>> 1 - pol_states
>> This field is listed as mandatory in §3.2 (Table 1, page 21) but then, Appendix B page 42, in Table 5 the MANdatory column says NO. After that, Table 6 on page 57 lists pol_states again among the mandatory fields.
>> 
>> This looks like simply a typo.
>> 
>> 2 - t_refpos
>> This field is listed in Table 5 (Appendix B) page 41 as an optional one, but has no other entry in the specification, e.g. it has no entry in Table 7 (Appendix C.2) so that no Utype or UCD is defined for it.
>> 
>> This one looks like a simple forgetfulness.
>> 
>> 3 - units for strings
>> Table 5 (pagg. 40-43) reports units for the various fields. However it defines string-type fields to be unitless except for s_region (no value is reported) and proposal_id (which is set as unit=string).
>> 
>> We think this is, again, only a minor typo since strings are unitless (blank in VOUnits).
>> 
>> Sorry for reporting this after ObsCore-1.1 reached REC.
>> How do you think we can fix this? Would an erratum (even a single encompassing one) do?
>> 
>> Cheers,
>>     Sonia & Marco
>> 
> 
> -- 
> --
> Mireille Louys
> CDS  						Laboratoire Icube 
> Observatoire de Strasbourg	Telecom Physique Strasbourg
> 11 rue de l'Université 		300, Bd Sebastien Brandt CS 10413 		
> F- 67000-STRASBOURG			F-67412 ILLKIRCH Cedex
> tel: +33 3 68 85 24 34

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20170926/798d4833/attachment.html>