Use Advanced Search to search the entire archive.
[jsr363-experts] Re: Sprint Q1/15 finished
- From: Werner Keil <
>
- To: "
" <
>
- Subject: [jsr363-experts] Re: Sprint Q1/15 finished
- Date: Sat, 4 Apr 2015 20:27:03 +0200
Hi,
After CLDR was also taken into consideration, I consolidated the quantities
list in
https://java.net/jira/browse/UNITSOFMEASUREMENT-100
Please have a look and check out which quantities are supported by each
catalogue/source (the number of quantities in javax.measure.quantity right
now is largely inspired by UCUM support)
As mentioned, CLDR is more compact and adds fewer "exotic" quantities and
units than either oBIX or UCUM.
Aside from 2 (AmountOfSubstance, LuminousIntensity) base quantities,
neither CLDR nor oBIX contain, all others are are provided by both of them.
Including 2 SI base units, a full CLDR content could therefore mean 20
quantities (including Dimesionless) instead of the 51.
Should we prefer all SI Derived Units, see
http://www.npl.co.uk/reference/measurement-units/si-derived-units/ (is this
list complete or missing anything substantial?) there may be a few extra
quantities Base+CLDR would not contain, probably around 25 quantities.
All others would move to a different module, either "uom-lib" or where
implementation-specific it could also be "uom-se" or others.
WDYT?
Werner
On Thu, Apr 2, 2015 at 3:53 PM, Werner Keil
<
>
wrote:
>
Dear Experts,
>
>
As "Q1" suggests, the first iteration after EDR1 was for the first quarter
>
of this year. It ended this week:
>
>
https://java.net/jira/secure/RapidBoard.jspa?rapidView=12&view=reporting&chart=sprintRetrospective&sprint=28
>
>
About a dozen tickets were closed. Many that rolled over are umbrella ones
>
like "Java ME compatibility", TCK or similar.
>
I closed the Spec Document with EDR, so for upcoming states like PD there
>
shall be new tasks. Likely similar with TCK, so we don't have some tasks
>
open forever.
>
>
The uom-tools project introduced to separate import/export functionality
>
for unit data like CLDR, oBIX, UCUM, etc. from the actual implementations
>
had its first outcome, too.
>
A manually refined list of all quantities oBIX knows compared to those
>
quantities we so far define in the API. See
>
https://java.net/jira/browse/UNITSOFMEASUREMENT-120
>
>
Please advise ideally in a separate thread what you think of full oBIX
>
support like the Fantom language does.
>
To guarantee type-safe operations within the framework of the API many new
>
types had to be added. Excluding currency (which is subject to JSR 354)
>
you'll find the Excel sheet useful to filter by colors like "green" (exact
>
match) or "yellow" (different word but same meaning) In total the combined
>
quantities for oBIX and existing (partly UCUM-based, I guess we may be able
>
to reduce some) types would at least be 75 interfaces.
>
>
I hope to get similar stats for CLDR (JSON is a bit more tricky than oBIX
>
in plain text, but I already got some data) maybe over the holidays. Gut
>
feeling tells me, there's a bigger overlap/synergy between CLDR units and
>
what we got, or we could eliminate a few base quantities from the main API
>
(and move them to an optional module on top)
>
>
Like UCUM oBIX also offers a losely typed dynamic option of reading the
>
text file. Essentially that's what uom-tools already does to analyse what
>
units and quantities exist. Whether we offer strongly typed oBIX support or
>
not, I guess that would be up to uom-se or another library, but not the RI.
>
>
Happy Easter,
>
>
Werner
>
>
Twitter @wernerkeil | @UnitAPI | @JSR354 | @JSR377 | @AgoravaProj |
>
#DeviceMap
>
| #DevOps | #EclipseUOMo
>
Skype werner.keil | Google+ gplus.to/wernerkeil
>
>
[image: --]
>
>
Werner Keil
>
[image: https://]about.me/wernerkeil
>
<https://about.me/wernerkeil?promo=email_sig>
>
>