UOMo Will Hand Developers a Clean Standards Based Solution.
Jaxenter speaks with initial UOMo committer Grahame Grieve, on this new weights-and-measures Eclipse project.
UOMo is a proposed Eclipse project for developers working with units and measures. We spoke with initial committer Grahame Grieve, to find out how UOMo fits in with the UCUM standard the Open Health Framework…..
JAXenter: What is the UOMo project?
Grahame Grieve: The UCUM standard defines a systematic way to allow computers to deal with units and measures without having to have semantic context. In the OHF project, we already implemented the core logic that is required for the implementation, but the OHF project is dispersing in multiple directions. The UOMo project is to pick up the UCUM part, give it it’s own home, and then leverage it as much as possible. In particular, to extend the Java compiler itself so it knows about units and measures.
JAXenter: UOMo aims to address issues surrounding modeling units. In your opinion, what are some of the problems a developer commonly encounters when modeling units of measure?
Grahame Grieve: There are really two problems. The first is that customary usage is ambiguous. There are multiple uses for symbols such as m and M. Humans can figure out which unit is meant by context, but developers can’t work like that. The second problem is the sheer complexity of the problem. There are thousands of units, and an unlimited number of possible combinations of units. And even with UCUM clearly describing the units, the logic to perform conversion is obtuse and complex. UOMo will hand developers a clean standards based solution to all this on a platter.
JAXenter: In the project proposal, it is stated that UOMo will focuses on ‘Java implementations.’What JVM languages – or other langauges, outside of the JVM – will UOMo support?
Grahame Grieve: It’s hard to say, because it will be based on demand. I myself have a full C# implementation which I am inclined to contribute. There is also a pure XSLT implementation that might be brought forward too. There has been some discussion about F# too, but really we are going to wait to see what develops.
JAXenter: The initial code contribution will consist of the UCUM component of the OHF project. What is the UCUM component?
Grahame Grieve: The UCUM component in OHF has 4 parts:
- a model for the XML definitions file that is part of the UCUM standard. These definitions drive the rest of the code.
- a model for a UCUM expression.
- a service that takes numbers of string units and performs validation and conversion on them.
- a series of JUnit tests.
At present, it is not well differentiated as a component – it’s just code in the H3ET (HL7 v3 editor tooling) component, so it will become more obviously separate.
JAXenter: Is the OHF still being developed?
Grahame Grieve: The OHF code is being moved around. Much has already gone to OHT (Open Health Tooling.)More is slated to go but hasn’t yet moved as it is not in active development at this time. Other parts are moving in to Equinox or other platform projects since they are not healthcare specific. The code that is left in OHF is still subject to occasional bug fixes, but it will be moved to OHT at some stage.