Quantitative criteria for accepting more unit usages

[sffc]

In response to my Intl Energy Units update, @js-choi asked for more details on the criteria for including unit usages. Currently we judge it primarily based on community involvement, which is a qualitative, non-objective approach. We should consider creating more specific criteria for unit usage inclusion.

https://docs.google.com/presentation/d/1iwknifQLEIA42KIoveoNLrRZlhEitZQ_JTKADP20rMA/edit?slide=id.p#slide=id.p

[ray007]

Maybe also take a look at https://ucum.org/ucum?

[js-choi]

Thanks for following up on this, @sffc. Yes, it’d be good to clarify scope more definitely.

1. At the plenary meeting, I brought up scientific and biomedical applications that use web platform technologies as collections of use cases that are quite similar to the electric-vehicle use case for kWh.

   • My own experience is in electronic health record systems (e.g., the largest one in the United States, Epic, uses JavaScript and Chromium for its frontend); EHR displays make extensive use of unit formatting (not only % or °F/°C but also mmHg and cmH₂O for blood pressures and gas pressures, mg and µg for any medication dosages, mg/dL and ng/dL for lab results, mmol, mmol/L, kcal for nutrition and fitness—see Units: Consider adding nutrition/energy units #713, others). FHIR-based health applications like Apple Health, Samsung Health, etc. also extensively use these units.
   • There are also lots of other scientific units used in other scientific applications. Pressures come to mind (atmospheres, PSI, bars and millibars, mmHg and cmH₂O again), and those would be used with vehicles as much as kWh would, as well as most weather apps.
   • I also second @erights's surprise that kelvin is not in the set. The kelvin is extensively used in the displays of not only scientific applications but also any applications that use light bulbs or kelvin-based light temperatures, such as 3D rendering software for architecture and digital art, photomanipulation software, etc., as well as much industrial software.

2. I think you said in plenary that each of these has to be considered on an ad-hoc basis, and that completionism (such as including all SI units) is expressly a non-goal. Nevertheless, it’d be good to have guidelines on what would be considered for inclusion and what would not be.

   • In particular, why might something be considered but then excluded? Why might radians (in graphing software), rotations per minute (in vehicle-related apps), or astronomical units, light-years, or parsecs (for astronomy applications) be excluded or included?
   • A usage criterion is probably most important—you want real-world use cases—but do you want your usage threshold to be very stringent and minimal, fairly broad and maximal, or something else?
   • I also imagine there would also be other exclusion criteria, e.g., no non-coherent units, humorous units, obsolete units, or fantasy units allowed.

3. (Somewhat related to this issue: It’d also be good to have guidelines for how to propose new units in general. Right now it seems to be filing a GitHub issue and soliciting upvotes, which might be fine for now, but it’d be nice to have a blurb in the explainer about this, as well as a GitHub issue template that goes over the criteria for new units. Well, actually, this suggestion would have been nice, if Intl Energy Units had its own repository instead of sharing it with all of ECMA-402’s other projects. The fact that this is all in one repository complicates the new-unit proposal workflow.)

4. (Also related: is accepting more units going to be a continuous process with ongoing review of new proposals even after Intl Energy Units reach Stage 4? That affects what criteria you need for accepting units to a great extent.)

My personal bandwidth is currently pretty limited, but if I find the time I’d be interested in helping out in the coming year. I definitely will try to make the ECMA-402 meetings. Thanks again; I’m excited about this proposal, and I wish the best of luck to its champions.

[sffc]

TG2 discussion: https://github.com/tc39/ecma402/blob/main/meetings/notes-2026-03-19.md#quantitative-criteria-for-accepting-more-unit-usages-1047