UCUM представление литра
Я запутался в том, как UCUM определяет символ "литр". Да, я знаю, что исторически символ l был использован, и что совсем недавно L был добавлен органами по стандартизации (см., например, BIPM SI 8th Edition) в качестве альтернативы l, Но я думал, что UCUM должен был дать нам один, однозначный набор символов для обмена.
Но читая UCUM более внимательно, я вижу, что он предоставляет как регистрозависимые, так и регистронезависимые версии символов. Более того, я вижу, что для чувствительности к регистру "литр" определяется дважды, один раз с учетом регистра символов l и другой с чувствительным к регистру символом L, Таким образом, я интерпретирую это так: если вы находитесь в чувствительной к регистру среде, на самом деле есть два литра символа, l а также L, и они оба означают одно и то же (фактически делая символ без учета регистра - блин!).
Поэтому, если я правильно интерпретирую это, это означает, что если программа поддерживает UCUM, и даже если она делает это с учетом регистра, _a программа UCUM всегда должна интерпретировать l а также L в качестве синонимов, включая производные единицы, такие как ml/mL, Это правильная интерпретация? UCUM заставляет нас делать поиск эквивалентности для определенных символов?
Правильная интерпретация UCUM имеет прямые последствия в его реализации. Возьмем, к примеру, JSR 363 (см. UCUM UnitFormat для JSR 363), который заменил JSR 275 (который якобы поддерживал UCUM, но никогда не делал), который получил поддержку UCUM и переместился в Eclipse UOMo; прочитайте ужасную историю. Так что я застрял с эталонной реализацией JSR 363, которая сериализует миллилитр как ml, Поэтому, когда UOMo наконец добавит поддержку UCUM для JSR 363, он распознает m"сериализация от JSR 363 RI и"mL"от UCUM как взаимозаменяемые?
Вернер Кейл говорит мне (в ранее упомянутой теме), что UCUM считает l а также L быть "двумя различными различными единицами". Но ucum.js считает их одинаковыми единицами.
Итак, вот мой конкретный вопрос: я использую JSR 363 RI для сериализации модулей, который производит l за литры. Я бы предпочел реализацию UCUM, но это все, что доступно прямо сейчас. Если я использую эту реализацию, она будет производить множество данных, используя l вместо L, Когда мой код будет наконец обновлен до реализации UCUM, будет ли он учитывать сериализованный в настоящее время l данные должны быть эквивалентны Lили он будет считать данные отличными от данных, использующих L единицы? Что, согласно спецификации UCUM, должно произойти?
Позвольте мне спросить об этом по-другому: скажем, я собираюсь написать свою собственную реализацию USR JSR 363. Если мой UnitFormat.parse(CharSequence csq) разбирает l а также L, если в результате unitLowercaseL.equals(unitUppercaseL) вернуть true или же false в соответствии со спецификацией UCUM и JSR 363?