obscore 1.1 - small issues

[alberto micol]

Of course ‘principal’ and not 'principle’…

> On 26 Sep 2017, at 14:08, alberto micol <amicol.ivoa at googlemail.com> wrote:
> 
> 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 <mailto: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/f7c980d0/attachment.html>