Hi Jonathan,
We have several topics of discussion going in this one email thread. I
have altered the Subject line of this particular response to focus a
discussion on a single topic -- the question of "provisional standards"
Jonathan Gregory wrote:
> Dear All
>
[...snip...]
>
> * In a sense, everything is provisional, in that we could always change it
> later (as we can do with aliases for standard names). However, we are always
> facing the problem that people want a convention to use straight away. Often
> they immediately use it to produce lots of data, or they even produce the
> data before the convention is finally agreed, since our discussions are slow.
> It does not really help in practice to say that the convention is provisional.
>
> If a mountain of useful data exists, changing the convention presents a
> problem of backward compatibility. That's not to say that we can't do it, but
> I conclude that what we have to do is think as carefully as possible (and as
> fast as possible) so that we decide wisely, and minimise the possibility of
> having to change afterwards. We should not have the approach that our decisions
> are prototypes so it is not so important to get it right, because prototypes
> have a habit of remaining in use, and when it is archived data that is
> concerned, not just software, this is even truer.
How one weighs this discussion depends upon what commitments the CF
rules include for a standards development *process*. Everything we read
about standards these days indicates the importance of sensible, but
iron-clad rules. I believe that we (CF, that is) have agreed upon a
process that states that before a new feature can be added to CF, 1)
reference files must be created and 2) clients that can read this data
must be created and tested.
Now, returning to the common case you have shone the spotlight on -- a
user has an urgent need for a feature that is not currently part of CF.
To accommodate his (or her) time tables we (the CF decision process,
that is) determine a solution in haste -- before test files and test
applications can be created. Such material I'd argue fits the
definition of "provisional". Suppose it turns out that later, after we
have created the test files and applications, that we regret some aspect
of the solution we invented. It is the designation of "provisional"
tells us all where the responsibilities lie. Namely -- it is our
responsibility as stewards of CF to get the standard "right" -- so we
fix our error. It is the responsibility of the data producer, who used
a provisional standard, to fix his/her erroneous files.
What the above seems to raise as the central issue is how do we ensure
that reference files and test applications will be created *quickly*?
We have failed quite badly on this point in the past. (Refer to
current discussions about a compliance Wiki. That is in recognition of
the large amounts of CF that have never been properly tested in code.)
One suggestion might be to place some of the burden for testing onto the
user who feels such time pressure to have changes made. A discussion
point ...
Of course I agree that we should think carefully, decide wisely and
minimize regrettable decisions. But it is inevitable that when we act
in haste we will make more mistakes and worse mistakes on average.
> A corollary, in my view,
> is that we must limit our scope to what is needed. We should certainly have an
> eye out for obvious generalisation that is likely to be required soon, but we
> need not try too hard to make predictions for future use.
>
I suppose it might be helpful to find words that will serve as a
guideline on this tough area. In my experience it is usually the
toughest, on-going area of decision-making in software development.
There are bad consequences for focusing either too far or too near
downstream.
good to have you back from your break! - Steve
[... snip...]
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
--
Steve Hankin, NOAA/PMEL -- Steven.C.Hankin at noaa.gov
7600 Sand Point Way NE, Seattle, WA 98115-0070
ph. (206) 526-6080, FAX (206) 526-6744
Received on Mon Nov 13 2006 - 10:39:55 GMT
