Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [emft-dev] Re: UOMo measurement and EMF

Hi Miles,
Yes currently Texo is more for the server side of web applications. This makes it also useful in other server-oriented scenarios.

gr. Martin

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@xxxxxxxxxxxxxx - mtaal@xxxxxxxxx
Web: www.springsite.com - www.elver.org
  

On Jul 5, 2010, at 6:49 AM, Kenn Hussey wrote:

Note that the EMFT Texo project may be of some use/interest here, as it provides support for automatically mapping between POJO and EMF implementations of a given domain model...

Wow, I wouldn't have even thought to look there because it is "advertised" for Web Applications. I just started looking at MoDisco as well and while that is advertised for legacy development there are a number of tools that would be useful in all kinds of contexts. These really useful bits of technology keep cropping up all over.

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.

I noted a mistake I made above and it turns out that this is a  perfect example of just how useful this approach could be and how the representational issues are deeper than they first seem. The attribute name is dimension, but the Measure is volume. Note that for some applications (medical dosing, say) the distinction isn't important, but in others (manufacturing) it obviously would be. Just as you can map / cast an integer to a BigNum safely, but not the other way around, you can make a dimension into a volume, but not do the inverse safely. Having a taxonomy of specificity could be really useful for this sort of thing. Or imagine I had a shipping application -- if I used DimensionCubicMeters I would be able to get linear feet. Or..let's say I have a bin packing problem, I might even be able to create a model for an object where I could have a DimensionalyConstrainedVolume for a composite of multiple packed objects that would be configurable in different ways -- and these constraints need not follow a rigid formula. You could call this the Ikea packing problem.. :) Or imagine that measures might work together so that for example if I have a climate model I might want to represent the notional volume of a specified air mass but that would be dependent on a  temperature and/or heat measure... 
_______________________________________________ emft-dev mailing list emft-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/emft-dev

Back to the top