VOTable and VOUnits

[Mark Taylor]

I believe we could write MUST without breaking the rules;
it's not true that previously valid VOTables would become invalid,
since only VOTables declaring version='1.5' would need to be
bound by new requirements introduced in VOTable 1.5.

But, my opinion is that we ought to stick with SHOULD at least for
now, and perhaps indefinitely.  It's nice if units can be
machine-readable, so VOUnit should be encouraged, but my guess is
that the overwhelming usage of the units attribute in VOTable is
being read by humans, and for that purpose non-VOUnit-compliant
units are much better than no units at all.
The danger of writing MUST here is that data providers who have a
load of human-readable-but-non-VOUnit-compliant units will provide
no units rather than rewriting them, to avoid compliance errors.

Regarding VOUnit enforcement elsewhere, I reviewed this (at the time)
in a talk I gave in Ops in the November 2021 virtual interop, and
I agree that VOUnit is not currently mandated anywhere.
The obvious place where this could be done apart from VOTable is
the unit element defined in VODataService 1.2 sec 3.5, which is
referenced from TAP 1.1 section 4 ("the information in the TAP_SCHEMA 
is equivalent to that defined by VODataService").

Mark

On Fri, 19 May 2023, Molinaro, Marco wrote:

> Hi,
> 
> I copy Markus' view on MUST/SHOULD.
> 
> I think the usage of VOUnits and its
> enforcement is unclear not only in
> VOTable.
> 
> Maybe we should enlarge the audience
> outside Apps: Semantics at least? DAL?
> Everybody?
> 
> In a sense VOUnits are enforced in no place
> (happy to be proven mistaken there), at least
> there's no mention in TAP apart from the
> architecture diagram.
> 
> Cheers
>     Marco
> 
> Il giorno ven 19 mag 2023 alle ore 09:53 Markus Demleitner <
> msdemlei at ari.uni-heidelberg.de> ha scritto:
> 
> > Hi Mark,
> >
> > On Thu, May 18, 2023 at 04:59:28PM +0100, Mark Taylor wrote:
> > > Do people have opinions on which it should be?
> >
> > Well: Can we get away with a MUST?  By the book, I don't think we're
> > allowed to do that, because it would make a large proportion of
> > VOTables that were previously valid invalid in one fell swoop.
> >
> > On the other hand, I don't think it has any *operational*
> > consequences in that things that worked before stop working (e.g., a
> > new client starts refusing old VOTables), and for all I care about
> > "breaking change" can only be sensibly defined operationally.  To
> > make that a bit clearer, we could even hedge a bit: "for historical
> > reasons, clients MUST NOT entirely reject VOTables with non-VOUnit
> > compliant unit strings; it is recommended to just treat such columns
> > as unitless and issue a warning".
> >
> > On the other hand: "issue a warning" is exactly what SHOULD is for.
> > So, I'd say we ought to have SHOULD in this version and perhaps
> > something like "it is planned to make this a hard requirement in
> > later VOTable versions" or so.
> >
> >           -- Markus
> >
> 
> 
> -- 
> Marco Molinaro
> INAF - Istituto Nazionale di AstroFisica
> Osservatorio Astronomico di Trieste
> email marco.molinaro at inaf.it
> tel. [+39] 333 33 20 564 [also Telegram]
> 

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          https://www.star.bristol.ac.uk/mbt/