@HDembinski, @jpivarski, please sign off if you like it (you can also suggest a name if you don't like "library").

I'd be confused by "library" out of context. If the field is filled in with the name of the software library, that would clue me in and I'd understand it, but I can't be sure I'd get it if I was supposed to fill in the field and I couldn't find the instructions.

"vendor" is more clear except that it implies that someone's selling something, which is almost always not the case for histograms. "header" is too generic.

I looked at JPEG EXIFs, and they use the word "maker" a lot.

XMP (used in formats like PDF) would use "contributors" for this. It inherits from the Dublin Core, but that's more intended for things like books that would name a human author as its creator, rather than a software library. Same for EPUB, which uses "dc:creator".

In the end, how about "software_library" and "software_library_version"?

What about writer_info (I added that after the initial issue)?

"writer_info" sounds good. There's still potential for confusion (among all these formats) between the human who authors the product and the software that generates it, but that confusion shouldn't come up as much with histograms as it does with books.

Do you want to separate out a version field? Otherwise, a single free-text field would get filled inconsistently with versioned and unversioned data, with a space, hyphen, or something else separating the library name from the version number. (It's probably not much of a problem, I'm just asking.)

The current proposal looks like this:

{
  "writer_info": {
    "boost-histogram": {
      "version": "1.0.0",
      (1) 
    }
  }
  (2)
}

The version is at writer-info/<library-name>/version. (1) is where a library can add any other metadata that they would like. For example, boost-histogram could record which axes had growth applied. That metadata is never required when reading a histogram. (2) is where the rest of the histogram is.

It's also possible that if we put all the format writers here in uhi, then it could even look like this:

{
  "writer_info": {
    "boost-histogram": {
      "version": "1.6.0",
    },
    "uhi": {
      "version": "0.6.0",
    }
  }
}

The version of boost-histogram that produced the serialization struct would be recorded, but also the version of uhi that converted that struct in to HDF5 or zip or zarr or whatever could also be recorded.

I am good with writer_info and the suggested use cases.

I see some conflict between the idea of using a structured storage format for what I understand is supposed to be metadata for human consumption. Using a structured format like a dict suggests that the information is designed to be read and used by machines. For pure metadata that is only for human consumption, I would use a string.

This is naturally (one level) structured data¹, and doesn't have to be only for human consumption. A utility like uproot-browser could show the library and version number if it's present. And the round trip example requires machine consumption. For example, boost-histogram could record {"writer_info": "axis_type": "Integer", "growth": True} on an axis, then when restoring an axis, it could restore the original Integer with growth axis instead of loading it as Regular or trying to guess that it might have been Integer based on heuristics. ROOT could store the original storage bit width. I think YODA histograms have some custom properties, though it's been a while since I was looking at that.

Even if improved round trip support isn't ever added when loading, it's better to allow the format to record this where we can access it if we want to later, rather than changing the format down the road. You could even just manually process the file and detect which axis were originally filled with growth on, for example. It's also generally more space efficient to not combine this into an arbitrary readable string. The important thing is that it's not required to read a histogram so libraries can load each other's histograms. It's basically exactly metadata but for library authors instead of users.

This now shares #162, so strings, numbers, and bools are the only allowed entries.

Okay to go in? Would like at least one okay to proceed, and I want to make progress before the next IRIS-HEP Demo Days, where I'll talk about histogram serialization.

Looks good to me!