Hi Sylvain, > My original comments about backwards compatibility weren't strictly right, I > realise. Allowing a domain variable reference instead of the usual data > variable attributes would not be a CF backward compatibility issue (though it > would be a little tough on software writers), but it would fall foul of > principle 10.
I did indeed mean "instead of" rather than "in addition to". Allowing a domain variable reference instead of the usual attributes would neither disallow the usual attributes, nor change their meaning, so no backwards incompatibility. This is similar to the `grid_mapping` extension that was introduced at CF-1.7. In this case the old single grid mapping case was still supported in the new version, but a new syntax was created for multiple grid mappings. This new syntax is not understood by software built on CF-1.6. > Being able to clearly identify the domain of a data variable, and therefore > the data variables that share a domain, is definitely an operation that could > be made simpler and this goal could be achieved very easily by a domain > variable reference. If the reference is an issue due to its nature, then one > could simply replace it by a unique identifier string, but if domain > variables are available then it would be a shame not to use them for that > purpose too. We shouldn't allow a domain variable instead of the usual domain definition because _a)_ there was no use case for it and _b)_ because it would require all software to be rewritten to support this different method. Even though allowing this would make it easier, in limited circumstances, to see "by eye" if two data variables shared a domain, I don't think that is a use case on its own. These limited circumstances only arise when informally comparing multiple data variables with domain references _within the same file_ (as opposed to the same dataset). Library software would not generally benefit from this as it has to store the constituent parts of the domain (cell measure, grid mappings, coordinates, etc) regardless of how it was encoded. If a stronger use case were to present itself in the future I would welcome this being reviewed, but suggest that for now we do not allow this. With regards the pre-existing redundancy issue, data variables are essentially independent entities. Therefore there is no redundancy if, say, two data variables have the same `coordinates` attribute value. We have to trust dataset providers to produce the datasets that they intend, and that is made easier by not allowing the same information to be encoded twice for each data variable. If this were allowed, and the two methods were inconsistent, we have no way of knowing which is correct. Anyway, I think (if I've read everything correctly) we are in agreement that a domain variable variable reference should not be used _in addition to nor instead of_ the usual domain definition (data variable `coordinates` attribute, etc). Which is good for the progress of this issue. Thanks, David -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/301#issuecomment-720546858 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
