don't use a field called items

[d-v-b]

Right now, GroupSpec has an items attribute (dict[str, TItem]). But items is a method on mutablemappings. Using items as an attribute is a) confusing, and b) prevents GroupSpec from inheriting from MutableMapping, because of attribute name overlap. We should change the name of the attribute to something that doesn't shadow a core python method.

[d-v-b]

possible new names for this attribute: contents, children, elements, stuff...

[clbarnes]

I'd vote for children, personally.

[d-v-b]

nodes is another option that just sprang to mind....

I think it would probably be good to promote this discussion to a ZEP outlining a standard JSON-serializable representation of a zarr hierarchy. Then we aren't solely responsible for naming decisions like this, and it's easier for other validation tools to simply copy the standard. Since you had an opinion in this issue, you have any objection to joining me on that ZEP? I'd probably get the ball rolling in the next few days.

[clbarnes]

It's only a very gentle opinion, but sure!

[clbarnes]

Thinking about it, isn't that serialized hierarchy exactly what's going to be needed for consolidated metadata? Is there already a consolidated metadata spec in zarr 2?

[d-v-b]

I couldn't find a proper standard for consolidated metadata. My quick googling turned up this: zarr-developers/zarr-specs#113, which kind of presages this issue.

I think the consolidated metadata uses a flat namespace for keys, which is convenient for mapping onto the zarr-python API but essentially bars the possibility of doing any static typing (in python at least), because the hierarchy levels all get merged together.

The consolidated metadata also uses the names of objects in storage for keys, e.g. .zattrs, which could be brittle if we think of the names of metadata files as an implementation detail that could change in future versions of zarr.

I see consolidated metadata as a solution to the problem of "I want to use the zarr-python API, but I only want to read one JSON document", whereas the representation in pydantic-zarr solves a different problem. I guess it's an open question if an abstract representation of the zarr hieararchy could be flattened to form a useful consolidated metadata document.

[jakirkham]

Adding other options: edges, leaves, nodes, kids, ninos, etc.

[d-v-b]

I think nodes wins here.

[clbarnes]

The spec refers mainly to "nodes" and when talking about nodes contained by a particular group, "child nodes" or "children". Could anyone incorrectly assume that "nodes" includes all descendants, or possibly the node itself, rather than just direct children?

[d-v-b]

Could anyone incorrectly assume that "nodes" includes all descendants, or possibly the node itself, rather than just direct children?

That seems possible.

@krokicki suggested "members", which I think is even better than "nodes". I'm leaning toward "members" unless there's any objections.

[d-v-b]

closed by #12