Skip to main content

[jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)

  • From: Werner Keil < >
  • To: "DAUTELLE, Jean-Marie" < >
  • Cc: " " < >
  • Subject: [jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)
  • Date: Tue, 7 Apr 2015 18:12:50 +0200

Jean-Marie/all,

Thanks for the quick reply.
*si.uom* is not the RI: https://github.com/unitsofmeasurement/si-units On
the contrary. It allows to hold everything that won't remain in the API but
is used or "accepted by SI" in an implementation neutral form. Unless there
are concrete classes like "SI" or others these reusable type libraries
contain nothing but additional interfaces to be compatible across all
implementations.

Cheers,
Werner


On Tue, Apr 7, 2015 at 5:45 PM, DAUTELLE, Jean-Marie <
>
 wrote:

>  Hi Werner and All,
>
> 3.      SI derived quantities (in javax.measure.quantity) + Dimensionless
> s. Table 2 (and mostly CLDR, too)
>
> We should stick with NIST Reference as much as we can. We have the chance
> to have an internationally recognized body to work with; let’s not reinvent
> the wheel.
>
> Also, these are typically the classes/interfaces which are the most
> important in the API (none of them should be in the RI).
>
>
>
> Cheers,
>
> Jean-Marie.
>
>
>
> *From:* Werner Keil 
> [mailto: ]
> *Sent:* mardi 7 avril 2015 15:27
> *To:* 
> 
> *Subject:* [jsr363-experts] [VOTE] Define quantities to remain in API
> (see UOM-100)
>
>
>
> Dear Experts,
>
>
>
> I hope you had a nice Easter holiday. Aside from brushing JSR 354 (which
> is heading towards Final pretty soon) I worked on the tools for analysis
> and comparison of different unit data sources which also lead to decision
> making of https://java.net/jira/browse/UNITSOFMEASUREMENT-100
>
>
>
> To get the core API even slimmer and a common understanding of quantities
> we would like there if any, I spawned-off a true SI module with a draft of
> all quantities currently in javax.measure:
> https://github.com/unitsofmeasurement/si-units/tree/master/quantity/src/main/java/si/uom/quantity
>
>
>
> uom.si is among the domains registered and while many folks and projects
> now rush towards their "io" domain (it's also a territorial domain btw. and
> exists for nearly 20 years http://en.wikipedia.org/wiki/.io) I got us "
> uom.si" (http://en.wikipedia.org/wiki/.si for Slovenia, other than Pepsi,
> there is nearly no company or project outside that country, which makes the
> domain a lot cheaper than "io" ;-) as a fairly unique place dedicated to SI
> units.
>
>
>
> Based on the NIST overview http://physics.nist.gov/cuu/Units/units.html
> please reply with your (+1) preference of having:
>
>    1. Nothing except Dimensionless (probably best in the SPI package)
>
>  2.      Only the 7 SI Base quantities plus Dimensionless (in
> javax.measure.quantity) s. Table 1
>
> 3.      SI derived quantities (in javax.measure.quantity) + Dimensionless
> s. Table 2 (and mostly CLDR, too)
>
> in the API?
>
>
>
> The delta from currently around 50 quantities should move to the SI module
> as long as they're commonly accepted for use with the SI system, e.g.
> http://physics.nist.gov/cuu/Units/outside.html
>
> This quantity catalogue is as platform-independent as the API itself, so
> RI, SE Port and other implementations may use it where appropriate. The RI
> will however probably stick to those few quantities we decide to keep in
> the API. While uom-se or other projects and implementations can use the
> extended SI catalog or additional quantities (to be defined elsewhere,
> likely under the non-SI UOM umbrella)
>
>
>
> Thanks,
>
>
>        Werner
>
>
> The information in this e-mail is confidential. The contents may not be 
> disclosed or used by anyone other than the addressee. Access to this e-mail 
> by anyone else is unauthorised.
> If you are not the intended recipient, please notify Airbus immediately and 
> delete this e-mail.
> Airbus cannot accept any responsibility for the accuracy or completeness of 
> this e-mail as it has been sent over public networks. If you have any 
> concerns over the content of this message or its Accuracy or Integrity, 
> please contact Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated virus 
> scanning software but you should take whatever measures you deem to be 
> appropriate to ensure that this message and any attachments are virus free.
>
>


[jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)

Werner Keil 04/07/2015

[jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)

Chris Senior 04/08/2015

[jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)

Werner Keil 04/08/2015

[jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)

Chris Senior 04/08/2015

[jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)

Werner Keil 04/08/2015

[jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)

Leonardo Lima 04/20/2015
 
 
Close
loading
Please Confirm
Close