1

I'm confused about how the UCUM defines the symbol for "liter". Yes I'm aware that historically the symbol l has been used, and that more recently L has been added by standards bodies (see e.g. BIPM SI 8th Edition) as an alternative to l. But I thought the UCUM was supposed to give us a single, unambiguous set of symbols for interchange.

But reading UCUM more closely, I see that it provides both case-sensitive and case-insensitive versions of symbols. Moreover I see that, for case-sensitivity, "liter" is defined twice, once with a case-sensitive symbol of l and another with a case-sensitive symbol of L. So the way I interpret this is that, if you're in a case-sensitive environment, there are actually two liter symbols, l and L, and they both mean the same thing (effectively making the symbol case-insensitive---sheesh!).

So if I'm interpreting this correctly, it means that if a program supports UCUM, and even if it does so in a case-sensitive manner, _a UCUM program must always interpret l and L as synonyms, including derived units such as ml/mL. Is that a correct interpretation? Is UCUM forcing us to do equivalency lookups for certain symbols?

Interpreting the UCUM correctly has direct consequences in its implementations. Take for example JSR 363 (see UCUM UnitFormat for JSR 363 ), which superseded JSR 275 (which purported to support UCUM but never did), which has had UCUM support pulled and moved to Eclipse UOMo; read the horrible story. So I'm stuck with a the JSR 363 Reference Implementation, which serializes milliliter as ml. So when UOMo finally adds UCUM support for JSR 363, will it recognize the m" serialization from JSR 363 RI and "mL" from UCUM as interchangeable?

Werner Keil tells me (in the previously mentioned thread) that the UCUM considers l and L to be "two different distinct units". But ucum.js considers them to be the same units.

So here is my specific question: I'm using the JSR 363 RI to serialize units, which produces l for liters. I would prefer a UCUM implementation, but that's all that's available right now. If I use this implementation, it will produce loads of data using l instead of L. When my code is finally upgraded to a UCUM implementation, will it consider the currently serialized l data to be equivalent to L, or will it consider the data to be distinct from data using L units? What does the UCUM specification say should happen?

Let me ask this another way: let's say I'm going to write my own UCUM implementation of JSR 363. If my UnitFormat.parse(CharSequence csq) parses l and L, should the resulting unitLowercaseL.equals(unitUppercaseL) return true or false according to the UCUM specification and JSR 363?

Community
  • 1
  • 1
Garret Wilson
  • 18,219
  • 30
  • 144
  • 272
  • Because JSR 363 RI doesn't support UCUM, and neither does JScience. I need to know whether to write my own implementation of UCUM, or if the default serialization provided by JSR 363 RI will be compatible with UCUM. See http://stackoverflow.com/q/42653545/421049 . See also https://github.com/unitsofmeasurement/uom-systems/issues/4 . – Garret Wilson Mar 07 '17 at 22:15
  • I'm voting to close this question as off-topic because it is not a programming question. – Joe Mar 09 '17 at 15:11
  • @Joe, I've updated the question to reflect more of my specific programming situation. Does that help? This is clearly related to a program I'm writing, and I'm trying to determine the correct serialization format (and appropriate serialization library) to use. – Garret Wilson Mar 10 '17 at 00:48
  • I will admit I don't know much about UCUM, but it doesn't read like a question a programmer would answer to me. It looks like something best asked in a forum specific to that implementation. Basically, you're not asking "how do I write a program for x", but you're asking "what is the specification for x non-programming thing". Similar to if I asked what the standard P-value was for a statistical test in an immunology journal, so I could write a program to do some tests. The question itself has nothing to do with programming, so it's off topic. – Joe Mar 10 '17 at 00:54
  • You're welcome to ask in [chat] though if you want to see if anyone else has a different opinion. The lack of traffic in two days suggests that this not necessarily get either answers or close votes, so it'll be in limbo for ... a while. Especially since it's in tags that have basically no followers (one of which you created for the question); unfortunately with SO's high traffic level, any question that doesn't have a tag anybody reads is likely to be impossible to find after a few days. – Joe Mar 10 '17 at 00:54
  • @Joe I see where you're coming from, but remember that this is not about implementing math or statistics --- it's about implementing a specification _for representing computer-processable data_. Without your meaning to, it's almost as if you're voting against my question because the subject isn't well known. For example, if I asked whether my ISO 8601 compliant parsing function for interoperability should consider `Z` equivalent to `-00:00`, I'd get all sorts of responses I doubt anyone would vote to close it. Yet I feel this current question is an exact analogy to one for ISO 8601. – Garret Wilson Mar 10 '17 at 01:22
  • I think your other question is on topic - it's a programming question. I think this question fails this test: `a practical, answerable problem that is unique to software development`. Your question is not unique to software development here; it's a question about the standard. I think a question about the ISO8601 standard that wasn't implementation-oriented would similarly be off topic. Your question above is basically a long discussion of the standard. As such it's off topic. – Joe Mar 10 '17 at 02:51
  • @GarretWilson: Problem is there is no [mcve] you ask about. To me it looks like you ask about how to interpret the standard, which would be POB. Only the standard's commitee could provide an authoritative answer about that. You lastest edit does not change it, but just tries to work around site rules. – too honest for this site Mar 10 '17 at 03:05
  • I'm not just trying to "work around site rules", but I do I understand where everyone is coming from. As soon as I get a free second (hopefully today or tomorrow), if there are no answers to this I'll send the question directly to the UCUM list and close this question here. Cheers. – Garret Wilson Mar 10 '17 at 18:23
  • For the record I've opened [UCUM Trac ticket 195](http://unitsofmeasure.org/trac/ticket/195) to try to get to the bottom of this. Feel free to continue closing this one if someone else agrees that it should be closed. On the other hand, if no one else agrees and instead wants to answer it, that would be fine, too. Whichever way it goes! Have a great week. – Garret Wilson Mar 13 '17 at 13:39

0 Answers0