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?