IVOA Errata, Identifiers for Obscore

[Markus Demleitner]

Dear lists,

The important stuff is below.  First, very briefly:

On Fri, Dec 06, 2013 at 01:54:07PM +0000, Mark Taylor wrote:
> On Wed, 4 Dec 2013, Markus Demleitner wrote:
> > And here the trouble starts.  First, I messed up.  For some reason I
> > cannot find, a bad identifier sneaked into the example in the
> > TAPRegExt draft; it lists ivo://ivoa.net/std/obscore-1.0 as the
> 
> From the department of the super-picky: as far as I can see, 
> TAPRegExt says "ivo://ivoa.net/std/ObsCore-1.0"
> (different capitalisation).  Since they are both wrong it obviously

This actually would need to be cross-posted to ReR, but IMHO it's a
minor thing -- IOVA Identifiers say:

  Identifiers are considered case-insensitive; however, the preferred
  rendering of character case in the ID is determined when its resource
  is registered.

This is one of these short sentences in specs that in my experience
cause no end of grief, but it's there, and we won't get rid of it.

My personal way of coping is ignore the stuff about "preferred" and
just have them all lower case whenever I can.  It's still a mess, but
IMHO a smaller one.


And now for the juicy bit:

> > (2) How can I clean up the TAPRegExt example as quickly as possible,
> > before even more implementors get confused?  Given that this is not
> > normative text on TAPRegExt's side, could we do some sort of fast
> > track?  Or can we add an erratum to the document entry page while
> > matters take their proper way?
[...]
> It would be nice to have an erratum page associated with each IVOA
> standard.  This could probably just be a wiki page, but should contain
> things which are known to be problematic and possibly workarounds.
> It would serve two purposes: first, act as a list of things that have
> to get fixed in the next version, and second, as a reference for
> implementors etc who are looking at the standard and scratching
> their heads wondering how the text can possibly make sense;
> often such things are known within the relevant VO (sub-)community
> but there's nowhere to record them.

Ah, I'm not so sure about the "things that have to get fixed in the
next version"; I'd like it very much if each document release
automatically had a wiki page for feedback of this kind associated
with it (this is basically what I'm trying to do with the TAP
Implementation Notes), but I feel such a thing will stir controversy.

Errata, on the other hand, have been around in scholarly publishing
basically forever.  I believe with some not-too-heavyweight process,
we could have them within a reasonable timeframe in the IVOA, too.
I'm now dreaming that "the TCG" might ask the SDP WG to change the
SDP document (somewhat) as follows:

  Add a section 1.6, "Errata", with the content:

  As necessary, a Recommendataion can be accompanied by an Errata page
  in the IVOA document repository.  Errata pages are versioned, i.e.,
  REC-1.0 and REC-1.1 will have different sets of Errata.

  Errata may not be used to change the normative content of a
  Recommendation.  They are intended both to allow corrections of
  non-normative material (examples, typographics, clarifications),
  and raise attention to specific issues with a Recommendation
  together with a recommendataion to its resolution.  Examples for
  the second type of Erratum include contradictions with other
  Recommendations, internal contradictions, or severe obstacles to
  implementation that have not been identified during the
  standardization process.

  Errata can be proposed to the chair or vice-chair of the Technical
  Coodination Group (TCG), who circulates the proposed Erratum on the
  TCG mailing list.  Every member of the TCG may veto the treatment of
  a piece of text as an Erratum on grounds that it introduces normative
  changes; if no veto has been brought up within two weeks, the Erratum
  is published in the IVOA document repository alongside the
  Recommendation.

  At every session, the Executive Committee reviews the Errata
  accrued since the last session.  The Executive Committee can
  withdraw an Erratum with single majority.  Such Errata will be
  marked as withdrawn in the document repository, possibly with a
  reference to a superseding Erratum.

It sounds a bit clunky, but then we're talking SDP here.  And I'd
really like "the TCG" to stand behind something like this, as it's
fairly profound on the one hand, but, as Mark says, is needed pretty
sorely.

Cheers,

        Markus