Viewing Nested Compound Datatypes

[Snore]

Is your feature request related to a problem?

I have a nested compound datatype I would like to view. The h5dump looks roughly like this:

HDF5 "./example.h5" {
GROUP "/" {
   DATASET "my_sincos_table" {
      DATATYPE  H5T_COMPOUND {
         H5T_COMPOUND {
            H5T_IEEE_F32LE "sin";
            H5T_IEEE_F32LE "cos";
         } "sincos_name";
      }
      DATASPACE  SIMPLE { ( 3 ) / ( H5S_UNLIMITED ) }
      DATA {
      (0): {
            {
               0,
               0
            }
         },
      (1): {
            {
               0,
               0
            }
         },
      (2): {
            {
               0,
               0
            }
         }
      }
   }
}
}

I cut down the data for this example.

When I open the h5 file in H5Web, it only shows me the raw output with no option to visualize it:

If I remove the outer nesting, there is no problem. If I change the outer nesting to a group, there is also no problem. This is a fabricated simplified example from a more complex nested compound type I am trying to use.

Requested solution or feature

I understand it would be hard to imagine how a user would want their complex nested compound type to be displayed. But I would personally be happy if the H5Web application somehow treated the outer compound types like a Group such that I could click deep enough into my structure's layout on the left hand panel and it would display a visualization much like if it were nested in a handful of groups.

Alternatives you've considered

I'm tinkering with artificially making some of these complex nested compound types groups in a post processing manner so that H5Web will cooperate. However, as some of these are already in other groups, it would add a small amount of confusion for the user that I am hoping to avoid.

Additional context

[axelboc]

It's something I've had in mind for a while but wasn't sure there was a real need for it, so thanks for opening an issue! I'd be curious to know more about your use case — i.e. what kind of data you're working with, and what visualization you're expecting to see and why.

So far, my thinking was to improve the Matrix visualization to support compound fields with "non-printable" type (i.e. other than int, float, boolean, enum, string and complex). If a field has a compound type for instance, we could imagine making the cells in that column clickable to explore the nested compound data.

So in your example, you would first see the Matrix vis with one column sincos_name and three rows; each of the three cells would be clickable; clicking on a cell would update the table to show the structure within that cell (so two columns, sin and cos, with one row if I'm reading the output of h5dump correctly). There would of course be a way to go back up to the previous level.

Would something like this meet your needs?

[Snore]

Thank you for your attention and interest in this matter!

The application is a framework, and one the framework's facets is that if you use an IDL (let's say something like protocol buffers as a stand in here) to define a message structure, we need to make code that will automatically capture that message and store it in an .h5 file if the user of the framework desires on a per message basis. As most IDLs allow you to compound and nest other defined messages, we also capture that relationship in the .h5 structure. We do want to reserve Groups for another feature, and as the h5 specification allowed for nested compound datatypes, we believed we had a solution.

However, these guys love your tool, and as we were prototyping nested compound types this came up as a problem when they tried to view the results.

The solution you provided in your last section would be better! But if we had the ability to view the original matrix view we would of have seen if we had only the sincos_name compound type without the outer compound type, that would be the best.

To say it a bit differently using your example, we would see the one column sincos_name and three rows as you have suggested. Then if we were to click on any of the cells under the sincos_name column, or maybe the sincos_name column itself, then the table would update with the sin and the cos column like before, but we would see all of the rows.

Or maybe clicking on the one cell would give you the one row table but clicking on the column header for the compound type give you all of the rows. The ability to see all of the rows together in their table form is the most important for our use case.