[emft-dev] Re: UOMo measurement and EMF

[Miles Parker <milesparker@xxxxxxxxx>]

Hi Grahame,

(Removing PMC)

> At present, the UCUM architecture is relatively simple: there's POJO models
> for the UCUM definitions and for a single unit expression (i.e. mg/mL). And
> there's an interface/implementation pair that takes the standard UCUM
> definitions as an xml file (which is part of the UCUM standard), and provides
> services such as converting from a BigDecimal value in one units expression
> to the right BigDecimal Value in another units.

Yes, that was along the lines of what I was thinking would be there. It's not insignificant to have that done and done right. :)

> 
> It would be simple to redo the two models in EMF, but I've never really figured
> out what that would get for anyone, other than getting EMF dependencies
> in the code, which would be a loss for some. 

Well first, I agree that you do no want to have EMF dependencies for the core representation. There are plenty of use cases where that would be a pointless and even onerous requirement. But there is no reason that you would need to. What I'm suggesting instead is to simply support an Ecore instance level implementation of the same set of interfaces. You could either do this by hand in Java and then add annotations to create the Ecore model, or (a better option I think) define them in Ecore and then produce the interfaces to a standalone plugin / jar. You should be able set up the code generation such that there are no explicit dependencies on Ecore itself. Then you could have a plugins that are:

1. POJO (again perhaps with annotations) Java Interfaces.
2. Common Java Implementations.
3. EMF Model Implementation likely but not necessarily using all aspects of 2.
4. Generic EMF Edit and Editor support.

> How could you leverage the EMF?
> What would it let you do?

A tremendous amount. If a common ecore-based model existed anyone who wanted to create an Ecore model and provide standard UOM would simply need to import the uom.ecore model and use the defined EClasses in their own model designs. Let's get specific..understanding that I don't know anything about the UCUM architecture per se so this could be way off in actual implementation.

Imagine I'm designing a model for an inventory system interfacing with CAD/CAM. I could define a BOM with an item that specifies a material that needs specific dimensions. Depending on how UOMo is designed I could a) define an attribute "dimensions" of type say VolumeCubicMeters or b) much better of type Volume and allow implementors to create an entry in any kind of measurement they wanted. Regardless of how I chose to represent or edit the values I would be confident that they could be safely and consistently translated into any measurement context. Which is again really a tremendously useful and reassuring thing to have *especially* if it can be done in a relatively light-weight way.

cheers,

Miles