@roy-lowry I was going to comment about the need to remove the deprecated 
`status_flag`  standard name modifier from the conventions document, but I see 
you agree that's necessary too.  That will help eliminate some confusion for 
newcomers to CF's ancillary variable/flag syntax and how to properly apply it, 
I think.  It confused me to have it mentioned in two places, anyway.


While coming up with this proposal, we were cognizant of the [discussion about 
the newly-added `quality_flag` standard 
name](http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2019/020995.html) over 
the summer/fall.  I see now, given that the `status_flag` standard name 
modifier is to be truly deprecated, our files will need to only use the 
specific standard names we've described above (which in a way inherit from the 
root `quality_flag` name), without use of any modifiers such as `status_flag`.  
Adapted example from earlier comment:

```
float sea_water_practical_salinity(time, z);
        sea_water_practical_salinity:standard_name = 
"sea_water_practical_salinity";
        sea_water_practical_salinity:ancillary_variables = 
"sea_water_practical_salinity_qc_agg";

int sea_water_practical_salinity_qc_agg(time, z);
        sea_water_practical_salinity_qc_agg:long_name = "Salinity QARTOD 
Aggregate Flag";
        sea_water_practical_salinity_qc_agg:standard_name = 
"qartod_aggregate_quality_flag";
```

I think it would be nice if the connection between our names and the 
`quality_flag` generic name could reflected better within the CF standard name 
table, since there's no explicit connection between them in the descriptions.   
We could change our name to follow a pattern like:

- quality_flag_aggregate
- quality_flag_gap_test 
- quality_flag_syntax_test
- etc...

and it would make the connection a little clearer.  At least they would start 
with the same letter and appear next to each other alphabetically, and might 
lead people to associate them more easliy.

Alternatively, we could mention `quality_flag` within the text descriptions of 
our new names.

Or, a new addition to 
[3.5](http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#flags)
 of the conventions document that explains the various names and includes a few 
examples?

Any thoughts out there about this?  

I see we're starting down a path that @graybeal mentioned in the quality_flag 
discussion with greater specificity in our names beyond the more generic 
`quality_flag` name.  Just wondering whether it makes sense to set a precedent 
here, and if so, what.  Maybe too much of a rabbit hole...


-- 
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/216#issuecomment-563339265

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].

Reply via email to