Dear Daniel and Charlie Thanks to you for the changes, and to Dave for reminding me where to find the "rich diff". I had forgotten which icon it is. Here are some comments on the latest version.
* Thanks for the extra definitions in chapter 1. I feel that "element" should not be included here because it's used in other senses elsewhere (for instance, in "elements of an array" in the "CDL syntax" entry of sect 1.2). It would be fine to use it in this sense in the group discussion, if you define it specifically there with that meaning. * "Local apex group" as defined here refers to the common ancestor starting from two different places, but that's not quite the sense in which you use it in chapter 2, it seems. Where you discuss "lateral search", "local apex group" appears to mean the very top of the tree. You search upwards until you hit the top, and if you haven't found it, you start the lateral search, top-down. * "Nearest" is defined as being according to the rules for finding things (in chapter 2). But in those rules, you use "nearest" to say how to find things! This is circular. (A means "see B" and B means "see A".) * In chapter 2, I am puzzled by the last sentence of "search by absolute path", which says, "Thus a variable `/g2/temperature` with coordinates attribute containing `/g1/lat` is permissible so long as there is no other `lat` dimension defined 'in between' those locations, e.g., `/lat`." I thought absolute meant absolute, but you're making it conditional. That's not what a Unix absolute path means. Could you explain what you mean here, please? I don't understand the preceding sentence either. * Search by proximity depends on a definition of "nearest" (see comment above). I think by "nearest" you mean the one which is reached by the smallest number of upward steps. Because downward steps aren't allowed this isn't the usual meaning of "nearest", so it's worth being clear. Usually you would say that a daughter was a near relation of a mother, but here a daughter is entirely discounted. * Lateral search. There is no problem with having many variables in a file with the same name if they're in different groups. As Daniel says, by itself that doesn't require the lateral search algorithm. As currently stated, the lateral search algorithm doesn't look well-defined, because it says it searches "across" each level, but doesn't specify what collating order "across" means. No doubt that could be defined as part of the algorithm. I understand that you want to allow this algorithm because there are many existing datasets which depend on it, but (a) the *existing* datasets aren't ever going to be CF datasets, unless they're all rewritten to insert an appropriate `Conventions` attribute; (b) for new datasets, couldn't the data-writers use a better convention than they currently do? In many applications, CF compliance means doing things in a slightly different way to before. If they aren't willing or able to change to absolute/relative/nearest paths, maybe you could define lateral search as a subconvention which they could use but most CF data-writers would not? * I have a fairly large number of reservations about the proposed Appendix I. Partly this is because I don't understand some of it, partly because I feel that it goes beyond what CF normally does in being prescriptive. If you're keen to include this in the convention, I think that more discussions in detail will be needed. I am keen on the approach in general and most of the details! I hope we will agree soon. Thanks for your efforts and patience. Best wishes Jonathan -- 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/144#issuecomment-428180024
