Hi @oceandatalab OK - we're in a slightly grey area here! This is where the [design principles ](https://github.com/cf-convention/cf-conventions/issues/273#issuecomment-656724527) can really help.
Principle 6 says "To avoid potential inconsistency within the metadata, the conventions should minimise redundancy." and principle 10 says "... there is a strong preference against introducing any new capability to the conventions when there is already some method that can adequately serve the same purpose (even if a different method would arguably be better than the existing one)." So to minimise redundancy, we should not allow both a domain variable reference _and_ the other data variable attributes to exist at the same time; and we shouldn't allow a domain variable variable reference anyway because we already have adequate (even if improvable) means of conveying the same information. 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. 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-709406316 This list forwards relevant notifications from Github. It is distinct from [email protected], 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 [email protected].
