Moving Top-Level Types or Package name of Unit-API

[keilw]

Gunther suggested, the Unit-API should consider the following while in the 'org.unitsofmeasure' namespace.

[19:03:34] Gunther Schadow: ideally you have one root under org.unitsofmeasure, e.g., org.unitsofmeasure.foobar

Currently I see 2 options:

a) move all that's in package org.unitsofmeasure including sub-packages to e.g. "org.unitsofmeasure.api" (which would meet the OSGi ID)

b) if this was too drastic and existing packages "quantity" and "util" acceptable, find at least a third one like "unit" similar to earlier JSR-275 structure

[keilw]

Preference by implementing parties is for a "unit" package beside "quantity" (and probably "util", unless that could be merged with "unit") From: "Martin Desruisseaux" <martin.desruisseaux@…> To: <unitsofmeasure@…> Sent: Monday, August 23, 2010 12:15 AM Subject: Re: [unitsofmeasure] Re: Units API

Le 23/08/10 00:02, Jean-Marie Dautelle a écrit :

My preference is to have two packages: org.unitsofmeasure.unit and org.unitsofmeasure.quantity

Same for me. I posted a comment on the issue tracker suggesting exactly that. Martin

[gschadow]

I think that is a problem.

This would mean that your implementation is the only Java implementation here. I think you need something to hold them together:

org.unitsofmeasure.jscience.unit org.unitsofmeasure.jscience.quantity

would that work? You can of course use whatever you call your software instead of jscience.

[keilw]

Thanks for the feedback,

Please note, none of this is a Java "implementation". The whole idea of the UCUM namespace was the most comprehensive "Spec" similar to something like "javax.measure" (where the sub-packages "unit" and "quantity" once existed in a similar way)

"jscience" on the contrary is one (of currently at least 3) implementation, so naming the Spec "jscience" was unacceptable. If "jscience" was to be used, then frankly there was no reason using "org.unitsofmeasure.*" instead of "org.jscience.*" ;-)

If you believe there must be room for more than one Spec under the "org.unitsofmeasure" namespace, then I'd go back to option a) either with the unchanged structure as is at the moment (just 1 level deeper) or a "hybrid" of moving the new "unit" and "quantity" still under an extra package like "api". Given the OSGi bundle Id this seems most natural, but other terms like "spec" would also work.

[gschadow]

I think it is important to keep in mind that your JSR work while being friends with UCUM is not directly related. You use UCUM codes as one of several but you provide a different framework. Because of this, we have to make sure that you do not present your API or its framework as representative of UCUM. Therefore to accomodate your code or documents under unitsofmeasure.org it needs to be in a separate heading, and not just with a generic name "API". Does your project have a name? You should give it a name that is distinct.

We also need to be sure that when you comment on UCUM questions as in #52, you don't just say that in your conceptualization you can do this or that without bringing it back to the UCUM view of things. I think this is important to avoid confusion.

[keilw]

Unit-API is the name, just like "Servlet-API" is the name of a framework/project that happens to be under javax.servlet. The first package was javax.unit or javax.units, before it was changed to javax.measure. So far still the most popular form as adaptions by Parfait among others show.

Having a Java API that is used by several projects like these not to mention Eclipse or JScience ultimately benefits UCUM allowing it to step out of a Healthcare-only niche. Of course only if that's in its interest?

Most commiters weren't too pleased about the extra package layer, but given analogies like "org.eclipse" as a top level, where you also have at least one more, they tended to understand that. Forcing to "make up" a name or worse, let's say call it "unitapi" instead of "api" sounds unproductive and damaging to adoption. Nor would "java" in the package name seem appropriate. Although I respect, there could some day in the future be another language implementation aiming to use such package. Anyway using the Java language it is what it is, a "Unit-API". And with "unitsofmeasure" in the name already, repeating that unnecessarily doesn't seem right.

Until a JSR was ever formerly created again, using javax is unacceptable. Nor is the term JSR-275 ever going to work again. It would be a new one if at all. JScience is only one implementation, so that earlier suggestion while well-meant is not going to do us any good here either.

Please advice on a reasonable package space. I noticed, your earliest Applets e.g. don't even use "org.unitsofmeasure" which at the time probably didn't yet exist. However, having other names like "applet" or "applets" available, one like "api" or "framework" wouldn't hurt such implementations. The idea of the "Spec", "API" or "Framework" is to give people guidance. We don't just conceptualize, we help them realize with our solutions.

[gschadow]

UCUM is already out of healthcare only niche. I am not doubting that we can cooperate. What I am having trouble with is have your API with different conceptualizations take over what UCUM is. The public would misunderstand that.

I would say that you are not forced to use the org.unitsofmeasure namespace as you note, the 3 implementations that I did for UCUM do not use that namespace either. But if you want to use it, you will have to give your specific project a specific name and put things under that layer. I am sorry if your committers don't like it, but we will have to do that to avoid confusion.

Finally your "applet" argument does not quite hold, because "applet" is not a generic name like "units" or "measure", but "applet" is like a brand name. Plus, it lives under javax, so there is no cause for confusion. If I was to put the parser of my yabba programming language which is an extension of Java under java.compiler I don't think that the Java ppl should accept that. It is a similar issue here.

[keilw]

I guess "applet" should be "servlet", those are under javax. If you created e.g. a Python artifact under something like "java.lang" it may cause confusion, but wouldn't be too likely to clash with any existing Java code on the other hand.

The only equivalent "Unit-API" names I found so far are also for different languages like Python or PHP (a project in Drupal)

You may agree, that "org.unitsofmeasure.unit-api" sounds nonsense, plus that package name is illegitimate in java. Taking all feedback so far, I think they wish to go elsewhere, although I see "org.jscience.measure" at least pushing it into a too scientific niche for broader acceptance and regognition by non-scientific projects.

Lowering priority. Since it is unlikely somebody will just make up a random project name, so it is likely to change completely.

[keilw]

Package name is org.unitsofmeasurement (purchased by Unit-API committer) resolving the name issue.