TAPRegExt erratum, Identifiers for Obscore

[Robert J. Hanisch]

I think it would be more consistent with the versioning system we have
been using for nearly 10 years to make an incremental (0.01 delta) release
of the document, note the errors that have been corrected in the change
log, and fix the problem in the main document.  If people don't bother to
look at the change log / erratum they will go on implementing the wrong
thing.

It was never the intention to make it onerous to fix minor problems with
documents.

If the WG Chair advises the TCG chair and IVOA chair that the nature of
the change is that of a correction, repair of a typo, etc., there would be
no need to go through the full-up review and sign-off process.

Bob

On 12/10/13 2:23 PM, "Patrick Dowler" <patrick.dowler at nrc-cnrc.gc.ca>
wrote:

>
>In my opinion, I think that the editor(s) and WD chair+vice-chair should
>be able to add Errata to the end of a document and republish it to the
>repository with the same version number. The date on the title page
>probably has to remain unchanged as that is the date it was recommended,
>so a secondary date might need to be added to the title page of the
>document if/when errata are added/modified.
>
>Errata would never change the text of the document -- only a section at
>the end (after Changes, before References).
>
>Thoughts? I can bring this up at the next TCG telecon to determine a
>path forward, but I don't think this would have any technical hurdles.
>
>Pat
>
>On 12/06/2013 05:54 AM, Mark Taylor wrote:
>>> (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?
>> I think this is a wider issue.  There is currently no lightweight
>> way of flagging up errata, or more broadly things which shouldn't
>> have been written into standards and need some further explanation,
>> for IVOA documents.  The only thing you can do is go through the
>> whole process of issuing a new version.
>>
>> 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.
>>
>
>-- 
>
>Patrick Dowler
>Canadian Astronomy Data Centre
>National Research Council Canada
>5071 West Saanich Road
>Victoria, BC V9A 2L9
>
>250-363-0044 (office) 250-363-0045 (fax)