Dear all, This might be obvious for everyone, but there should probably be version numbers attached to the conventions CF wishes to incorporate. This would prevent possible damage when an external convention is first incroporated by CF, and then forks in a development path that is no more compatible with CF. We do not want "external convention foo" to be incorporated at every stage, but rather at a given date/version.
As an example, could we think of udunits (udunits2) as a convention that has been "incorporated" by CF for handling the units? If so, what happened when udunits2 was made authoritative: was the transition from CF point of view under control or not? By the same token, should we think of some wordings for CF to quit (deprecate the use of) a previously incorporated convention? Regards, Thomas ----- Original Message ----- > -------- Original Message -------- > Subject: Re: [CF-metadata] Proposed addition to CF principles: outside > conventions > Date: Mon, 21 Nov 2011 14:39:13 -0700 > From: Seth McGinnis <mcgin...@ucar.edu> > To: John Caron <ca...@unidata.ucar.edu> > > Hi John, > > I'm generally in favor of this proposal. The value of standards lies > in their > widespread adoption, so if a popular solution already exists, we > should adopt > it and bolster both standards rather than creating yet another > competing > option. > > It also make sense to delegate the design of a convention to those > communities > that needed it more urgently and therefore have focused more on it > than the CF > community has. > > Cheers, > > --Seth McGinnis > > > On Mon, 21 Nov 2011 07:56:02 -0700 > John Caron <ca...@unidata.ucar.edu> wrote: > >The following is being proposed to add to CF principles, and comments > >from all > >would be welcome: > > > >"CF may incorporate an outside convention into it when the following > >conditions hold: > > > > 1. The semantics of the convention are important to the CF > > community. > > 2. The convention is already in wide use by other communities, and > > the > > adoption by CF significantly helps other communities adopt CF. > > 3. The convention is not in conflict with existing CF standards. > > 4. In the case that the new convention overlaps existing CF > > conventions, software should be developed to detect > > inconsistencies > > and provide feedback to the data producer. > > > >" > > > >The current context is the proposal "Specification of Coordinate > >Reference > >System properties in Well-Known Text format" : > > > > https://cf-pcmdi.llnl.gov/trac/ticket/69 > > > <https://cf-pcmdi.llnl.gov/trac/ticket/69#comment:31> > > >however, the intention is for this principle to guide future CF > >proposals > >also. > > > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- ========================================== Thomas Lavergne Norwegian Meteorological Institute P.O.BOX 43, Blindern, NO-0313 OSLO, Norway Phone: (+47) 22963364 Fax: (+47) 22963380 Email: t.laver...@met.no OSISAF HL Portal: http://osisaf.met.no ========================================== _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
