Skip to main content

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

  • From: Werner Keil < >
  • To: " " < >
  • Subject: [jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)
  • Date: Tue, 2 Jun 2015 10:47:50 +0200

Ok, thanks. Anything that is pruned from the API should be available in a
dedicated new SI-Units module:
https://github.com/unitsofmeasurement/si-units/tree/master/quantity
So any application or standard that needs the "Full SI" (including other
extensions like UCUM) would add this type definition on top of unit-api.
Any overlap will be removed there btw.

Then we'll stick to Table 1 (7 base units), Table 3 (22 named units) and as
much as we feel is appropriate from Table 2 plus the obvious Dimensionless.

Werner








On Mon, Jun 1, 2015 at 11:44 PM, Martin Desruisseaux <
>
 wrote:

>  Hello Werner
>
> Le 20/05/15 14:30, Werner Keil a écrit :
>
> One exception we'd like to keep is *AngularSpeed *(previously
> AngularVelocity) since GeoAPI references the latter, so we would like to
> remain consistent with this downstream standard avoiding it to require
> extra dependencies.
>
>
> Thanks a lot for caring. But I just had a check and saw than
> AngularVelocity is mentioned in the documentation, but not actually used
> in the API. So I think that we do not need to take GeoAPI in account for
> that quantity. I'm somewhat neutral on keeping it. But if it is the only
> remaining unit not mentioned by standard organisations, maybe it would be
> safer to omit it at least for now.
>
>     Martin
>
>


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

Martin Desruisseaux 06/01/2015

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

Werner Keil 06/02/2015
 
 
Close
loading
Please Confirm
Close