StandardsRegExt: endorsedVersion/@standard and Endorsed Notes

Molinaro, Marco marco.molinaro at inaf.it
Tue Aug 23 12:24:22 CEST 2022


Hi Markus, ReR,

I personally don't like (a), nor I understand
why "n/a" is there,  considering the purposes
set in the specification introduction.

(b), (c), and (d) look quite the same to me, in
the sense that they only differ by urgency level.

ENs and PENs are, IMHO, just another path towards
standardisation, so it would make sense to revise
the list of values for the EndorsedVersion status
attribute (not enough for a vocab? probably yes).

I consider it more important answering the questions
in (d) than start fixing the spec itself (so, sort
of (b) with (d) on the way).

It looks like you already have a talk skeleton in
your mail, so, if it's not too much burden for you,
I'd vote for listening that talk and, maybe, have a
gather-splinter with interested people.

Cheers
    Marco

Il giorno mer 27 lug 2022 alle ore 14:46 Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> ha scritto:

> Dear Registry folks,
>
> I recently had to write a standards record for UAT adoptions endorsed
> note, and while doing that I noticed that I cannot do that properly.
>
> That's because the StandardsRegExt schema restricts the status
> attribute of endorsedVersion to
>
>   "rec" | "pr" | "wd" | "iwd" | "note" | "n/a"
>
> (which is all there was when the standard was written).  I went for
> n/a for the UAT EN, since "note" is even... wronger (does that word
> even exist?).
>
> So... what do we do?  I see a couple of ways to deal with this:
>
> (a) We ignore it and use n/a for Endorsed Notes.  I don't think
> there's a big technical problem with that, since I don't think
> anything is using endorsedVersion/@status operationally.  But then I
> notice substantial activity in the ugly hack alert network whenever I
> think about that solution.
>
> (b) We ignore it and just don't register Endorsed Notes.  That's
> probably not a big deal at this point, but it would be once an
> Endorsed Note wants to define ivoids (something like
> ivo://ivoa.net/std/mystd#feature-a).  Perhaps ENs simply shouldn't do
> that and be RECs if they need this kind of thing?
>
> (c) We add "en" (and, for completeness "pen" in case one day we
> reflect our standards process in the Registry, which would be kind of
> cool) to StandardsRegExt.  This would mean version 1.1, which someone
> would have to prepare.
>
> (d) Like (c), but we also review StandardsRegExt for a few points
> that IMHO have been missing so far, like
>
> * What do we register?  Only RECs that need ivoids?  All RECs and
>   ENs?  All applicable IVOA documents including Notes?  If so: why?
>   What's the use case(s)?
>
> * When do we register standards?  Only when a REC is published or already
>   during PR?  At WD publication time?  [registering IWDs as
>   suggested by the schema IMHO makes no sense at all]  Again: Why?
>
> * Who gets to change the StandardsRegExt records (like: add keys)?  The
>   editors?  Other people?  Is that perhaps up to the standard to
>   define that?  Who has to review such changes?
>
>
> Personally, I'm undecided between option (a) and option (d) at this
> point, with option (d) preferred if someone else than me does it :-).
>
> I starting to want to give a talk on this at the next interop --
> should I?
>
>            -- 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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20220823/a9783337/attachment.htm>


More information about the registry mailing list