Hi Jonathan, Thanks for this input - I share your sentiment and also hope that we can reach a positive conclusion soon. I'll respond to your points inline below. All of these changes are reflected in the [updated PR](https://github.com/cf-convention/cf-conventions/pull/145/files#diff-72315029966a0acd1d12ff8e03994c88).
> 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. I see what you mean about the use of "element" in other parts of the Convention, particularly in reference to individual items within an array. I've reviewed our proposal and don't see a reason to define "element" specifically, and thus I've removed the definition from the glossary. > "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. This is true. I've also modified the wording in that section of the proposal; you can find it in the updated version. @czender please correct this if I have misunderstood how the lateral search works. > "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".) I hope to have resolved this by changing the "Search by proximity" text as follows: "A variable or dimension specified with no path is the variable or dimension of the same name which can be found via a search of direct ancestor groups with the shortest number of intermediate groups. For example, a `coordinates` attribute of `lat` refers to the `lat` variable (if any) in the present group. If the variable or dimension is not in the referring group then it is termed an out-of-group reference. Out-of-group references are resolved by searching all direct ancestors, starting from the direct ancestor and proceeding toward the root group, until the specified variable or dimension is found." Do you find this clearer? > 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. I see what you mean here, actually I think this is just a byproduct of text being moved around a lot. I've changed those three sentences to read: "When referencing out-of-group variables, it is the responsibility of the dataset producer to ensure that the dimension(s) utilized by the out-of-group variable are the same as those used by the referring variable." The intent here is to make sure that you don't refer to e.g. an auxiliary coordinate variable which uses different dimensions than the referring variable. If a data producer were to do this, it would not be possible to match the coordinates to the variable calling them up; the original text was designed to prevent this. However, the two sentences you referred to were in the wrong spot, and in my opinion they're not needed anyway, as the scoping rules clearly explain how that should work anyway, so I've deleted them and moved the whole block into the "Scope" section. > 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. Right. I think that the newest version is clearer and reflects this unambiguously. > 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? @czender I'll pass this to you, as the King of Lateral Search :) > 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. What would you suggest for the appendix? Correct me please if I'm wrong, but I don't think that the appendix is prescriptive - the title is "**Recommended** Practices and Annotated **Examples** for Using Groups" so I see no danger that people would see this as a prescription. At the last meeting in Reading my feeling was that the community felt that having examples as guidance for different data types would be helpful; we've included them in the appendix with the intent of providing such examples without being prescriptive. I'm happy to discuss this in greater detail, and I don't want to regard your reservations, but I need more information about what they are in order to try to address them :) Best regards, Daniel -- 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-428596905
