@martinjuckes asked: > This looks likely to cause confusion, as some software may consider them as > different. Wouldn't it be better to at least recommend that they have the > same data type?
I actually had exact type match in one of my drafts, then thought about it and changed to simple compatibility. If type match is either required or recommended, this adds responsibility and complexity on both data creators and conformance checkers. Much existing software provides easy comparison between mixed types. Some software goes a step further and reads netcdf input to generalized types, such as ingesting both `string` and `character` as undistinguished internal strings. E.g. NCAR's own NCL language, ever since the addition of the new netcdf type `string`. I think the cost of exact type match exceeds any benefit. Also I think this draft statement of type compatibility merely clarifies the status quo for CF policy on data type of boundary var attributes. Further thoughts? -- 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/265#issuecomment-738965653 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].
