<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hi Markus, ReR,</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">I personally don't like (a), nor I understand </div><div class="gmail_default" style="font-family:monospace">why "n/a" is there, considering the purposes </div><div class="gmail_default" style="font-family:monospace">set in the specification introduction.</div></div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">(b), (c), and (d) look quite the same to me, in </div><div class="gmail_default" style="font-family:monospace">the sense that they only differ by urgency level.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">ENs and PENs are, IMHO, just another path towards </div><div class="gmail_default" style="font-family:monospace">standardisation, so it would make sense to revise </div><div class="gmail_default" style="font-family:monospace">the list of values for the EndorsedVersion status </div><div class="gmail_default" style="font-family:monospace">attribute (not enough for a vocab? probably yes).</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">I consider it more important answering the questions </div><div class="gmail_default" style="font-family:monospace">in (d) than start fixing the spec itself (so, sort </div><div class="gmail_default" style="font-family:monospace">of (b) with (d) on the way).</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">It looks like you already have a talk skeleton in </div><div class="gmail_default" style="font-family:monospace">your mail, so, if it's not too much burden for you, </div><div class="gmail_default" style="font-family:monospace">I'd vote for listening that talk and, maybe, have a </div><div class="gmail_default" style="font-family:monospace">gather-splinter with interested people.</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><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mer 27 lug 2022 alle ore 14:46 Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Registry folks,<br>
<br>
I recently had to write a standards record for UAT adoptions endorsed<br>
note, and while doing that I noticed that I cannot do that properly.<br>
<br>
That's because the StandardsRegExt schema restricts the status<br>
attribute of endorsedVersion to <br>
<br>
"rec" | "pr" | "wd" | "iwd" | "note" | "n/a"<br>
<br>
(which is all there was when the standard was written). I went for<br>
n/a for the UAT EN, since "note" is even... wronger (does that word<br>
even exist?).<br>
<br>
So... what do we do? I see a couple of ways to deal with this:<br>
<br>
(a) We ignore it and use n/a for Endorsed Notes. I don't think<br>
there's a big technical problem with that, since I don't think<br>
anything is using endorsedVersion/@status operationally. But then I<br>
notice substantial activity in the ugly hack alert network whenever I<br>
think about that solution.<br>
<br>
(b) We ignore it and just don't register Endorsed Notes. That's<br>
probably not a big deal at this point, but it would be once an<br>
Endorsed Note wants to define ivoids (something like<br>
ivo://<a href="http://ivoa.net/std/mystd#feature-a" rel="noreferrer" target="_blank">ivoa.net/std/mystd#feature-a</a>). Perhaps ENs simply shouldn't do<br>
that and be RECs if they need this kind of thing?<br>
<br>
(c) We add "en" (and, for completeness "pen" in case one day we<br>
reflect our standards process in the Registry, which would be kind of<br>
cool) to StandardsRegExt. This would mean version 1.1, which someone<br>
would have to prepare.<br>
<br>
(d) Like (c), but we also review StandardsRegExt for a few points<br>
that IMHO have been missing so far, like<br>
<br>
* What do we register? Only RECs that need ivoids? All RECs and<br>
ENs? All applicable IVOA documents including Notes? If so: why?<br>
What's the use case(s)?<br>
<br>
* When do we register standards? Only when a REC is published or already<br>
during PR? At WD publication time? [registering IWDs as<br>
suggested by the schema IMHO makes no sense at all] Again: Why?<br>
<br>
* Who gets to change the StandardsRegExt records (like: add keys)? The <br>
editors? Other people? Is that perhaps up to the standard to<br>
define that? Who has to review such changes?<br>
<br>
<br>
Personally, I'm undecided between option (a) and option (d) at this<br>
point, with option (d) preferred if someone else than me does it :-).<br>
<br>
I starting to want to give a talk on this at the next interop --<br>
should I?<br>
<br>
-- Markus<br>
</blockquote></div><br clear="all"><div><br></div>-- <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>