StandardsRegExt: endorsedVersion/@standard and Endorsed Notes

[Markus Demleitner]

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