obscore 1.1 - small issues

[Arnold Rots]

Huh? Principal,  perhaps?

On Sep 26, 2017 2:09 PM, "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> 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
<https://maps.google.com/?q=300,+Bd+Sebastien&entry=gmail&source=g>
Brandt CS 10413
F- 67000-STRASBOURG			F-67412 ILLKIRCH Cedex
tel: +33 3 68 85 24 34 <+33%203%2068%2085%2024%2034>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20170926/dec26517/attachment-0001.html>