Dear Daniel and Charlie
Thanks for this proposal. I think it's a sensible way to support groups, and I
agree with it, except that 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 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? If it's
reversible, that would be neat.
I feel that the text could be made simpler and easier to understand, and most
of my suggestions below are along those lines. Although I think I get the
spirit of your search rules, I have to say I don't properly follow them in
detail. The text seems obscure to me - maybe you could say it more plainly, and
diagrams would help, I expect.
* 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.
* 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"?
* For the first sentence of the new Groups subsection, I would suggest, "Groups
provide a mechanism to structure data hierarchically within files." It doesn't
seem especially "powerful" to me - it's just what you'd expect it to be! It's
also not the only way, since hierarchy can equally well be done with
directories.
* 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?
* Say what an "identifier" is and in which contexts in CF it can occur. What is
a "location"?
* "Resolves to" is programmatic jargon - could you say this in more ordinary
language?
* 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.
* In a path, is `.` allowed? Is `//` allowed?
* 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.
* In "Search by absolute path", what does "nearest dimension" mean?
* In "Search by absolute path" you use the phrase "out-of-group", before its
definition, which appears further down.
* 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".
* 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`.
* 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 hope that helps. 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-411055132
