Dear Jonathan, Thanks for reviewing this.
# Inline responses I'm responding to your comments inline and abridging as I determine relevant; if there's anything you're missing, let me know. > ... I'm not convinced about the lateral search. You don't sound convinced > about it either, in saying that it's allowed for backward-compatibility and > may be deprecated in future. Why not deprecate it now (meaning that the > CF-checker would give a warning)? Why allow it at all? Is there a more > specific extra search rule you could provide instead of your general lateral > algorithm to deal with the existing datasets you have in mind? I have to agree with you on this, and this is in line with my understanding of the discussion at the meeting in Reading. @czender could you say a few words on this? > I think that at the meeting we talked about how you would flatten a file, if > you didn't want groups. Could we include that aspect in the proposal? @czender has some nice material on this in [the original proposal](https://github.com/diwg/cf2/blob/master/group/cf2-group.adoc#mapping-between-hierarchical-and-flat-files) which I omitted for brevity. Would you propose importing this section (possible in edited form) into the pull request? I struggled with not adding too much text to the Conventions themselves, but we could include it as an appendix chapter. I do worry about overloading people new to the game with text. > The text seems obscure to me - maybe you could say it more plainly, and > diagrams would help, I expect. Diagrams are always good. In the original proposal we had:  To my knowledge it would be the only diagram in the whole of the Conventions. As a new contributor I didn't want to snub current practices, but I see no problem with including it, if the community is happy with that. > In ch01 you propose a number of definitions. However, you don't propose to > use these terms anywhere in the convention outside your new subsection of > ch02. Hence I suggest you start your ch02 subsection with these definitions, > instead of putting them in ch01, so they're in the place where the reader of > ch02 will see them. I don't really agree with this - having multiple glossaries scattered throughout the document only makes the terms easy to find if everybody is reading them in electronic form, and in that case we could just as well define terms next to their first use. So I prefer to keep all definitions together, as has been done for all the other definitions thus far. > You haven't defined what you mean by ancestor group, sibling group, > descendant group, identifier and element. Why not say "nearest" instead of > "most proximal"? What does "nearest" mean in the description of "local apex > group"? I think it would be a good idea to add these to the glossary. @czender, do you have an opinion on "nearest" vs. "most proximal"? > Are "object" and "element" the same? If so, I'd use only one of these terms, > and "element" seems better to me because it's not language-specific. Say what > sort of thing can be an "element" - a dimension? a variable? of any role? @czender I see no difference here and propose adopting "element". Please correct me if I'm overlooking something. > Is the convention of paths to name groups and elements something that you are > defining here as part of CF, rather than built into netCDF? I guess that it > is, and if so, I would state explicitly that you are doing so, because it > reads as though you assume the reader knows what is meant by a path to a > group. As part of this, please explain how to interpret a path. I understand what you're saying here, but since we say that paths are treated as UNIX paths, I think it would be overredundant to describe how to follow a path according to the UNIX conventions. Do you think it would be valuable to link to the [POSIX pathname resolution specification](http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11)? The same comment applies to your following bullet point, which I have omitted. > Does the restriction on out-of-group refs ("The dataset producer etc.") apply > only to the case of absolute paths, or in all cases? If the latter, it should > be stated before or after the three cases, I suppose. You're right, this should be noted at the beginning of the chapter, since it applies to all out of group references. For our reference I note that it's in `ch02.adoc`, line 190. > In "Search by proximity", say what "with no path" means. What's a "direct > ancestor" - I mean, could an ancestor be "indirect"? I would combine the Note > with the paragraph which follows, because in the Note it's not obvious what > strategy you're talking about i.e. the "special case". Agreed, I think we can describe this more clearly in the next update. > I think that you shouldn't list the attributes concerned, because this is > redundant within the convention. This information is in Appendix A. If it's > repeated here, it'll probably become inconsistent. If you want, you could > give just a single example from each list e.g. title, units. I agree with that too. > Is the last paragraph saying that groups can have attributes, like global > attributes? If so, please say that - "being present within" sounds vague. > Does a group attribute override a global attribute? Are global attributes > assumed (unless overridden) to apply to all variables in all groups? I > suggest that this part should come in the same place as the text about global > attributes, before the text about variable attributes. I think that (what is > currently) the last sentence isn't necessary - that's implied by the previous > sentence, isn't it? I agree that precedence should be clearly stated when group attributes conflict with global attributes. # Next steps We'll update the PR to address the points as noted above and ping again when that's been done. In addition to the items noted explicitly, I propose placing the following new terms in the glossary: - Element (or object) - Identifier - Location - Resolves to - or change language - Nearest dimension - Ancestor, sibling, descendant group -- 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-413214515
