<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace"><span style="font-family:Arial,Helvetica,sans-serif">Il giorno ven 19 mag 2023 alle ore 11:54 Mark Taylor <<a href="mailto:m.b.taylor@bristol.ac.uk">m.b.taylor@bristol.ac.uk</a>> ha scritto:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I believe we could write MUST without breaking the rules;<br>
it's not true that previously valid VOTables would become invalid,<br>
since only VOTables declaring version='1.5' would need to be<br>
bound by new requirements introduced in VOTable 1.5.<br>
<br>
But, my opinion is that we ought to stick with SHOULD at least for<br>
now, and perhaps indefinitely.  It's nice if units can be<br>
machine-readable, so VOUnit should be encouraged, but my guess is<br>
that the overwhelming usage of the units attribute in VOTable is<br>
being read by humans, and for that purpose non-VOUnit-compliant<br>
units are much better than no units at all.<br>
The danger of writing MUST here is that data providers who have a<br>
load of human-readable-but-non-VOUnit-compliant units will provide<br>
no units rather than rewriting them, to avoid compliance errors.<br>
<br>
Regarding VOUnit enforcement elsewhere, I reviewed this (at the time)<br>
in a talk I gave in Ops in the November 2021 virtual interop, and<br>
I agree that VOUnit is not currently mandated anywhere.<br>
The obvious place where this could be done apart from VOTable is<br>
the unit element defined in VODataService 1.2 sec 3.5, which is<br>
referenced from TAP 1.1 section 4 ("the information in the TAP_SCHEMA <br>
is equivalent to that defined by VODataService").<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace">Right, I missed that one.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Trying to answer the request for more easily readable </div><div class="gmail_default" style="font-family:monospace">specifications (e.g. from talks in last week's interop),</div><div class="gmail_default" style="font-family:monospace">we might put an issue on both VODataService (which is </div><div class="gmail_default" style="font-family:monospace">not in github, AFAIK) and TAP to clarify the texts there.</div><div class="gmail_default" style="font-family:monospace">Similarly to what's up here in VOtable.</div><br></div><div><div class="gmail_default" style="font-family:monospace">Would that help? Is it too much?</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Cheers</div><div class="gmail_default" style="font-family:monospace">    Marco</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Mark<br>
<br>
On Fri, 19 May 2023, Molinaro, Marco wrote:<br>
<br>
> Hi,<br>
> <br>
> I copy Markus' view on MUST/SHOULD.<br>
> <br>
> I think the usage of VOUnits and its<br>
> enforcement is unclear not only in<br>
> VOTable.<br>
> <br>
> Maybe we should enlarge the audience<br>
> outside Apps: Semantics at least? DAL?<br>
> Everybody?<br>
> <br>
> In a sense VOUnits are enforced in no place<br>
> (happy to be proven mistaken there), at least<br>
> there's no mention in TAP apart from the<br>
> architecture diagram.<br>
> <br>
> Cheers<br>
>     Marco<br>
> <br>
> Il giorno ven 19 mag 2023 alle ore 09:53 Markus Demleitner <<br>
> <a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>> ha scritto:<br>
> <br>
> > Hi Mark,<br>
> ><br>
> > On Thu, May 18, 2023 at 04:59:28PM +0100, Mark Taylor wrote:<br>
> > > Do people have opinions on which it should be?<br>
> ><br>
> > Well: Can we get away with a MUST?  By the book, I don't think we're<br>
> > allowed to do that, because it would make a large proportion of<br>
> > VOTables that were previously valid invalid in one fell swoop.<br>
> ><br>
> > On the other hand, I don't think it has any *operational*<br>
> > consequences in that things that worked before stop working (e.g., a<br>
> > new client starts refusing old VOTables), and for all I care about<br>
> > "breaking change" can only be sensibly defined operationally.  To<br>
> > make that a bit clearer, we could even hedge a bit: "for historical<br>
> > reasons, clients MUST NOT entirely reject VOTables with non-VOUnit<br>
> > compliant unit strings; it is recommended to just treat such columns<br>
> > as unitless and issue a warning".<br>
> ><br>
> > On the other hand: "issue a warning" is exactly what SHOULD is for.<br>
> > So, I'd say we ought to have SHOULD in this version and perhaps<br>
> > something like "it is planned to make this a hard requirement in<br>
> > later VOTable versions" or so.<br>
> ><br>
> >           -- Markus<br>
> ><br>
> <br>
> <br>
> -- <br>
> Marco Molinaro<br>
> INAF - Istituto Nazionale di AstroFisica<br>
> Osservatorio Astronomico di Trieste<br>
> email <a href="mailto:marco.molinaro@inaf.it" target="_blank">marco.molinaro@inaf.it</a><br>
> tel. [+39] 333 33 20 564 [also Telegram]<br>
> <br>
<br>
--<br>
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bristol.ac.uk" target="_blank">m.b.taylor@bristol.ac.uk</a>          <a href="https://www.star.bristol.ac.uk/mbt/" rel="noreferrer" target="_blank">https://www.star.bristol.ac.uk/mbt/</a><br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><font face="monospace">Marco Molinaro</font></div><div><font face="monospace">INAF - Istituto Nazionale di AstroFisica</font></div><div><font face="monospace">Osservatorio Astronomico di Trieste</font></div><div><font face="monospace">email <a href="mailto:marco.molinaro@inaf.it" target="_blank">marco.molinaro@inaf.it</a></font></div><div><span style="font-family:monospace">tel. [+39] 333 33 20 564 [also Telegram]</span><br></div></div></div></div></div></div></div>