Skip to article frontmatterSkip to article content

HDF5 Enhancement Proposals (HEPs)

Gathering the Best Ideas from the HDF5 Community

The HDF5 project has quietly enabled breakthroughs across science, engineering, and industry for over two decades and counting. This success is no accident. HDF5’s open specification, public-domain status, and wealth of fundamental storage features have enabled portability of HDF5 data on nearly every computing platform, with support in all popular programming languages. This has encouraged the HDF5 community to experiment and create various solutions for how to store their data in HDF5.

Better to Work Together

Until now, these creative solutions have been fragmented, limiting opportunities for cross-community adoption of proven storage techniques. While HDF5’s flexibility fosters a wide range of data storage options, this diversity also introduces redundancies. Unifying common storage practices can significantly enhance the usefulness and interoperability of HDF5-based software across different parts of the community.

This website and its associated GitHub repository make up the collaborative hub for the HDF5 community to propose, discuss, and adopt new storage ideas and techniques. Although HDF5 has been around for a while, it’s better ever than never to have a community resource like this one. The hope is it will be adopted over time and lead to reduction of duplicate effort and, eventually, to HDF5 data with more shared data storage features. Let’s make the effort of HDF5 software developers more impactful!

The Enhancement Proposal Process

All activities are based around enhancement proposals. They should all be related to HDF5, either specific software or how to store certain type of data. Below are the rules that guide the HEP process, which will be adapted as needed:

  1. All proposals have the Creative Commons Attribution 4.0 International Public License (CC BY 4.0).
  2. All work is voluntary.
  3. Proposals can be in two stages: draft and accepted. 1.A draft proposal becomes accepted after a process involving cycles of reviews, followed by a community vote. The details are TBD.
  4. Proposal authors must state any deadline, funding, contractual, or commercial requirements related to their proposal.
  5. An accepted proposal cannot be changed besides errata or updates about software implementations if applicable. Major changes must be a new proposal.
  6. Proposals are not versioned. They are referenced by their number, for example, HEP967 or their URL.