Hi All,
Just to add a wrinkle to this discussion: I can imagine a situation in
which a subconvention doesn't conflict with CF (because it either requires
a sub-set of CF options, or requires options outside of CF that CF doesn't
regulate) but in the future CF gets updated in a way that does conflict
with the subconvention. In that case, I assume that the sub-convention
will have to be associated with particular versions of CF.
I don't know how much of a problem this will be in practice since CF seems
fairly mature now.
Best wishes,
Philip
On Thu, 3 Sep 2009, Jonathan Gregory wrote:
> Dear John
>
>> i think the common use case is this: a group already has their data using
>> their own convention, possibly even documented(!). now they want to get on
>> the CF bandwagon so they are going to try to be CF compliant without
>> breaking their existing software. I dont see how we can disallow that,
>> since CF explicitly allows other metadata. if there are conflicts, then I
>> agree this should not be allowed. it does argue for us to resolve the
>> namespace problem, eg CF:attname = value.
>
> I suppose that if there are no conflicts, then you can actually regard it as
> a subconvention. That is, the group accepts all of CF, and adds some more
> (whether restrictions or new facilities). In that case, the / syntax could
> be used. I can see that this is a bit imperialist, in that it requires the
> group to label CF as their main convention, but it does have the advantage
> of not requiring any new syntax, just what the netCDF user guide allows.
>
> Cheers
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
------------------------------------------------------------------------
Dr Philip Cameron-Smith Atmospheric, Earth, and Energy Division
pjc at llnl.gov Lawrence Livermore National Laboratory
+1 925 4236634 7000 East Avenue, Livermore, CA94550, USA
------------------------------------------------------------------------
Received on Thu Sep 03 2009 - 10:55:59 BST
