New Eclipse Project

UOMo Will Hand Developers a Clean Standards Based Solution.

Jessica Thornsby

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

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

Grahame Grieve: The UCUM component in OHF has 4

- 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.

comments powered by Disqus