UCD problem in SSA/SpectrumDM

[Christophe Arviset]

Doug

Please note that numbering such as 1.04, 1.05 are not supported anymore 
in the agreed Naming and version numbering conventions 
(http://www.ivoa.net/Documents/DocStd/20090302/PR-DocStd-1.2-20090302.html).

Cheers

Christophe

Doug Tody wrote:
> 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
>>
>>

-- 
Thanks in advance

Cheers

Christophe


-------------------------------------------------------------------
Christophe ARVISET                       Christophe.Arviset at esa.int

European Space Agency (ESA)
European Space Astronomy Centre (ESAC)
Science Operations Department
Science Archives and Computer Support Engineering Unit

P.O. Box 78
28691 Villanueva de la Canada                 Tel: +34 91 813 12 78
Madrid - SPAIN                                Fax: +34 91 813 13 08
------------------------------------------------------------------- 


================================================================================================
This message and any attachments are intended for the use of the addressee or addressees only. The
unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content
is prohibited. If you received this message in error, please delete it from your system and notify
the sender. E-mails can be altered and their integrity cannot be guaranteed. ESA shall not be liable
for any e-mail if modified.
=================================================================================================