Skip to main content

[jsr363-experts] Re: Understanding UOM issues

  • From: Werner Keil < >
  • To: Anakar Parida < >
  • Cc: " " < >
  • Subject: [jsr363-experts] Re: Understanding UOM issues
  • Date: Mon, 2 Mar 2015 17:31:57 +0100

I also just created a ticket with the question of a possible name change
for SystemOfUnits: https://java.net/jira/browse/UNITSOFMEASUREMENT-122
Please simply comment on the JIRA ticket, that's easier to track than a
reply via email (only if you really had no JIRA account on java.net, feel
free to reply here;-)

Thanks,
Werner

On Mon, Mar 2, 2015 at 12:39 PM, Werner Keil 
< >
 wrote:

> Dear All,
>
> Allow me to follow up on an important aspect which is modularization and
> introducing somewhat flexible unit data sources.
> For the RI, we'd have some alternatives, and there should be only one data
> source built-in, likely the CLDR to match what the JDK does otherwise or
> Unicode/ICU (but with a smaller footprint than ICU4J;-)
>
> This UK site provides a nice overview of SI base units:
> http://www.npl.co.uk/reference/measurement-units/
>
> This French one (our French experts may also check it in French;-)
> http://www.french-metrology.com/en/si/units-measurement.asp
> highlights a challenge we face regarding the number of derived units and
> quantities to include
> >We must not believe, however, that once set up, this system is fixed.
> Progress made in science and technology and the new requirements from
> society and therefore the >needs in terms of increased accuracy, will led
> the LNE and all national metrology institutes to continuously improve the
> practical realisation of all SI units. And this concern >involves the
> references as well as the means for transfer to the users, to allow
> matching at best these new needs. Definitions of units sometimes need to be
> changed and new >definitions added.
>
> For other implementations like UOM-SE (and where required ME-compliant
> modules may also exist with the same functionality) we should define
> alternate unit data sources.
> An interesting argument especially to solve the symbol/name dilemma some
> unit systems and their current implementation (mostly via JScience) showed,
> could be a look at JSR 108 successor UCAR. Especially the UnitDB:
> https://www.unidata.ucar.edu/software/thredds/v4.3/netcdf-java/v4.0/javadocAll/ucar/units/UnitDB.html
>
> JSR 108 itself first brought up methods like UnitFormat.label() which we
> abandoned in Unit-API 0.6 (org.unitsofmeasurement) but some of them could
> make sense. Either there or in a similar form as UCAR's UnitDB.
> Offering system-wide aliases and handling of such symbols and names.
> Thus a UnitSystem implementation (a shorter name for SystemOfUnits) like
> SI not only offers constants like AMPERE, METRE,... it is backed by 2
> UnitDB implementations, one base units the other derived units (which also
> co-relates to a few issues Martin brought up around SystemOfUnits)
> Have a look at a GitHub copy of UCAR if you want:
> https://github.com/ctrueden/ucar-units Some of it feels over-blown,
> especially the huge number of exceptions, etc. but it doesn't mean we
> should not look for a few inspirations, especially related to better
> handling of unit systems and sources (not sure, if we'd really call it Unit
> DB btw. that sounds a bit archaic like from an RDBMS era;-D)
>
> Regards,
>
> Werner
>
>
> On Thu, Feb 19, 2015 at 3:16 PM, Werner Keil 
> < >
> wrote:
>
>> Anakar/all,
>>
>> While most other tickets you mentioned have their SE pendant,
>https://java.net/jira/browse/UNITSOFMEASUREMENT-114 an umbrella for
>> other tasks related to UCUM removal from the RI are specific to the
>> Reference Implementation only. However, to make it easier for others who
>> wish to help outside the EG and possibly make some of the new approaches
>> like using Unicode CLDR, oBIX, etc. available to both RI, UOM-SE or further
>> implementations (e.g. Eclipse UOMo) I spawned a new repository
>https://github.com/unitsofmeasurement/uom-tools
>>
>> It's inspired by "i18n tools in the JDK" or similar artifacts. Mostly
>> command line tools helping to convert say JSON data from Unicode/CLDR into
>> another format, be it properties or generated Java classes. A few files
>> like a JSON file from CLDR shall be moved there (currently reside in
>> unit-ri)
>> I created a Waffle.io board for tools, as well
>https://waffle.io/unitsofmeasurement/uom-tools, so that it's independent
>> from JIRA (while there could be occasional relations to JSR JIRA tickets
>> tasks or tools created there are more or less independent from the actual
>> RI or TCK)
>>
>> Both adopters and experts have push access to uom-tools.
>>
>> Regards,
>>
>> Werner
>>
>>
>>
>>
>> On Thu, Feb 19, 2015 at 10:54 AM, Werner Keil 
>> < >
>> wrote:
>>
>>> Hi, Anakar,
>>>
>>> Thanks for the message. Note, the issues in JIRA refer to the RI, so
>>> while Raj as EG member could also work on those, at least direct code
>>> changes by non EG-members are not supposed to take place. I know there's a
>>> "Partner Membership" for JUGs in the making, not sure, if this will change
>>> things, but for now, we consider everybody (a person, not an organization)
>>> who is not a full EG member "adopter" or "observer", ("contributor" is not
>>> currently defined by the JCP, after 364 goes final, we'd be able to 
>>> mention
>>> those most dedicated as "contributors" after they joined JCP either as
>>> Affiliate or via their JUG)
>>>
>>> Most or all of above should have a "mirror" in GitHub, see
>>> https://waffle.io/unitsofmeasurement/uom-se. Btw. you can also do
>>> "Planning-poker" style sizing of tasks. Being an  Agile advocate and coach
>>> in many projects (especially the ones that lead me to India once were
>>> almost entirely Agile gigs[?]) I find this appealing, and it could give
>>> those interested an idea about the size and effort. If you already got
>>> Waffle enabled, please think about
>>> https://github.com/unitsofmeasurement/uom-se/issues/54 and
>>> https://github.com/unitsofmeasurement/uom-se/issues/60 ;(the 3 GitHub SE
>>> "mirrors" of JIRA tickets mentioned above) and give them a size you'd 
>>> guess
>>> (these are just "story points" no actual hours or days to work on[?])
>>> Ideally in future no GitHub/Waffle tasks should be put in "ready" if they
>>> have no story point assigned first.
>>> If you change something on the SE side, feel free to also comment in
>>> JIRA, that makes it easier to get them in sync, unless it's a pure SE
>>> feature like "using Lambdas" which we won't duplicate in the RI.
>>>
>>> I closed https://github.com/unitsofmeasurement/uom-se/issues/53 after
>>> marking it as duplicate. It got more formalized in
>>> https://github.com/unitsofmeasurement/uom-se/issues/54.
>>>
>>> Thanks and Regards,
>>> Werner
>>>
>>>
>>>
>>> On Thu, Feb 19, 2015 at 4:30 AM, Anakar Parida 
>>> < >
>>> wrote:
>>>
>>>> Hi Werner,
>>>>
>>>> I went through the below issues
>>>>
>>>> 1. https://java.net/jira/browse/UNITSOFMEASUREMENT-78
>>>> 2. https://java.net/jira/browse/UNITSOFMEASUREMENT-114
>>>> 3. https://java.net/jira/browse/UNITSOFMEASUREMENT-108
>>>> 4. https://java.net/jira/browse/UNITSOFMEASUREMENT-109
>>>>
>>>> As per my understanding
>>>> Issue-78 needs to be looked into.
>>>> Issue-114 is subdivided into 2 more parts. One part is fixed and the
>>>> other is in progress.
>>>> Issue-108 depends on Issue-109 so it is on hold.
>>>> Issue-109 depends on 2 more issues that is Issue-114 and Issue-103.
>>>> Issue-114 is in progress as mentioned earlier. Issue-103 is still open.
>>>>
>>>> Out of these issues which are the one you need me to concentrate into.
>>>> So that it wont happen in such a way that there will be 2 person end up
>>>> fixing the same issue. Since the few issues are in progress I want to 
>>>> know
>>>> what are the issues you want me to concentrate into to start with. 
>>>> Overall
>>>> I have read every issues mentioned above. Once I get the green signal I
>>>> will start digging into the specific issues. :)
>>>>
>>>> Regards
>>>> Anakar Parida
>>>>
>>>
>>>
>>
>

Attachment: 329.gif
Description: GIF image

Attachment: 347.gif
Description: GIF image



[jsr363-experts] Re: Understanding UOM issues

Werner Keil 03/02/2015

[jsr363-experts] Re: Understanding UOM issues

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