UCD problem in SSA/SpectrumDM

[Doug Tody]

Hi -

We already have protocol versioning support in these interfaces,
and for it to work properly it is important to observe these rules
as Bob notes below (in addition this represents standard practice
outside astronomy as well).  So very minor changes or minor document
clarifications without changing the intent might be a level 3 revision
(1.04 -> 1.05); addition of new features while remaining backward
compatible a level 2 (1.0 -> 1.1), and non-backwards compatible or more
extensive changes (a major new version) a level 1 revision (1 -> 2).

In the current case the UCD error Alberto noted is not used as part
of the actual SSA interface, so it is a minor change.  Data providers
are already allowed to specify the UCD in many cases for the data
they are describing.  A UTYPE change on the other hand is more
serious as UTYPEs are the basis for identifiying data model elements
in SSA.  If we change any important UTYPEs the new version will not
be backwards compatible.  This is why I suggested that, unless the
changes are quite minor (we don't know yet), re-aligning SSA with a
newer version of Char may need to wait until a version 2.0 (e.g. once
the dust settles on TAP, SIAV2, and UTYPE and all the little changes
they are likely to foster).

> legitimate mistakes.  At the level of typos I would hope we could agree that
> these could simply be fixed, e.g., with the oversight of the standing
> committee on process.  A new version of the document (with date of issuance
> revised) would replace the previous one and changes duly noted in the change
> log part of the paper.

I would support this.  The new document version and possibly a revision
note of some sort should be sufficient here.

 	- Doug


On Tue, 24 Nov 2009, Robert Hanisch wrote:

> On 11/24/09 5:48 AM, "Keith Noddle" <ktn at star.le.ac.uk> wrote:
>
>>> Indeed, as stated by Ray, even "minor" revisions should go through the
>>> recommendation process.
>> I wish to point out that I did also state this in my reply to Doug on
>> 20th; there never was any doubt that even the most minor of changes
>> requires full approval - I was trying to suggest that the extent of the
>> change will be proportional to the time approval takes, that's all.
>>
>> What doesn't seem clear to me is whether the IVOA has mandated that
>> minor revisions MUST be backwards compatible with previous revisions of
>> the current document (i.e. V1.6 MUST be backwards compatible with V1.1
>> etc). Maybe I've missed it somewhere, but if it isn't explicitly stated
>> then IMHO it should be.
> Hi Keith.  This is stated explicitly in Section 1.2 of the standards process
> document:
>
> " After a document reaches Recommendation status, subsequent revisions
> retrace the promotion process.  Changes that are backward compatible result
> in increments in the number to the right of the decimal place (1.1, 1.2,
> ...).  Changes that are not backward compatible require an increment of the
> number of the left of the decimal place (2.0), with subsequent backward
> compatible revisions following the same pattern (2.1, 2.2, ...)."
>
> Having been one of the architects of this review and promotion process, this
> discussion makes me wonder whether we need a more expedient way to deal with
> legitimate mistakes.  At the level of typos I would hope we could agree that
> these could simply be fixed, e.g., with the oversight of the standing
> committee on process.  A new version of the document (with date of issuance
> revised) would replace the previous one and changes duly noted in the change
> log part of the paper.
>
> For mistakes such as the incorrect UCD that led to this discussion the
> situation is not black-and-white.  Such a mistake causes changes to code,
> which invokes the "new version" rule, but hardly seems to require engaging
> the entire review machinery.  Of course, allowing things into this gray area
> becomes a matter of judgment (by whom?), and risks a foray into
> arbitrariness.  Maybe we need a lightweight "re-review" process for such
> situations.  In any case, let's try to not get out of control with rule
> making, lest we have to start hiring legal counsel into all of our teams!
>
> Your approach of gathering things together makes sense to me.
>
> cheers,
> Bob
>
>