UCD problem in SSA/SpectrumDM

[Mireille Louys]

Hi Doug, Hi all

Sorry for the double posting DAL+DM, But I fear to mis anybody.

I created a page for the revision of the Spectrum Data model document at
http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/SpectrumDMUpdate

Here we can list the typos, and small updates needed for the revision of 
ucd and utypes inconsistencies.
I just started to extract comments from the discussion.

I guess the same can be done for the revision of the SSA document.

Cheers, Mireille.


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
>>
>>
>


-- 
--------------------------------------------------------------
!! Please notice my phone number has changed!!
 Mireille LOUYS          mailto: mireille.louys at unistra.fr
                                      
L S I I T                       &     CDS,
Ecole Nationale Superieure            Observatoire de Strasbourg    
de Physique de Strasbourg,            11, Rue de l'Universite
Boulevard Sébastien Brant, BP 10413   67000 STRASBOURG
67412 ILLKIRCH Cedex       	      Tel: +33 3 68 85 24 34
---------------------------------------------------------------