forked from ucum-org/ucum
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathucum.xml
17859 lines (17490 loc) · 817 KB
/
ucum.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="utf-8"?>
<!-- COPYRIGHT 1998-2014, REGENSTRIEF INSTITUTE, INC. AND THE UCUM ORGANIZATION ALL RIGHTS RESERVED.
Use and redistribution of this data is permitted without charge
as long as you make no changes to it. DO NOT CHANGE THIS FILE if
you want to redistribute it. Please contact Gunther Schadow at
the Regenstrief Institute, Indianapolis, IN 46260 for any issues
that make you think you need to change this file.
-->
<spec xmlns:u="http://aurora.regenstrief.org/UCUM">
<header>
<title>The Unified Code for Units of Measure</title>
<version>2.1</version>
<revision>$Revision: 441 $</revision>
<date>$Date: 2017-05-20 18:32:47 -0400 (Sat, 20 May 2017) $</date>
<authlist>
<author>
<name>Gunther Schadow</name>
<affiliation>Pragmatic Data LLC</affiliation>
<email href="[email protected]"/>
</author>
<author>
<name>Clement J. McDonald</name>
<affiliation>National Library of Medicine, Lister Hill</affiliation>
<email href="[email protected]"/>
</author>
</authlist>
<copyright>1998-2014, Regenstrief Institute, Inc. and the UCUM Organization. All rigthts reserved.</copyright>
</header>
<body>
<div1 id="section-introduction">
<head>Introduction</head>
<p>
<emph>The Unified Code for Units of Measure</emph>
is a code system intended to include
<emph>all</emph>
units of
measures being contemporarily used in international science,
engineering, and business. The purpose is to facilitate unambiguous
electronic communication of quantities together with their units. The
focus is on electronic communication, as opposed to communication
between humans. A typical application of
<emph>The Unified Code for Units of Measure</emph>
are electronic data
interchange (EDI) protocols, but there is nothing that prevents it
from being used in other types of machine communication.
</p>
<p>
<emph>The Unified Code for Units of Measure</emph>
is inspired by and heavily based on ISO 2955-1983, ANSI
X3.50-1986, and HL7's extensions called “ISO+”. The
respective ISO and ANSI standards are both entitled
“Representation of [...] units in systems with limited
character sets” where ISO 2955 refers to SI and other units
provided by ISO 1000-1981, while ANSI X3.50 extends ISO 2955 to
include U.S. customary units. Because these standards carry the
restriction of “limited character sets” in their names
they seem to be of less value today, when graphical user interfaces and
laser printers are in wide-spread use. For this reason, the european
standard ENV 12435 in its clause 7.3 declares ISO 2955 obsolete.
</p>
<p>
ENV 12435 is dedicated exclusively to the communication of
measurements between humans in display and print, and does not provide
codes that can be used in communication between systems. It does not
even provide a specification that would allow communication of units
from one system to the screen or printer of another system. The issue
about displaying units in the common style defined by the 9th
<emph>Conférence Générale des Poids et Mesures</emph>
(CGPM) in 1947 is not just the character set. Although the
<emph>Unicode</emph>
standard and its predecessor ISO/IEC 10646 is
the richest character set ever, it is still not enough to specify the
presentation of units, because there are important typographical
details such as superscripts, subscripts, roman and
italics.
<footnote>
<p>
Interestingly the authors of ENV 12435 forgot to include
superscripts in the minimum requirements as given by subclause 7.1.4
for which they do not specify an alternative.
</p>
</footnote>
</p>
<p>
The real value of the restriction on the character set and
typographical details, however, is not to cope with legacy systems and
less powerful technology, but to facilitate unambiguous communication
and interpretation of the meaning of units from one computer system to
another. In this respect, ISO 2955 and ANSI X3.50 are not
obsolete because there is no other standard that would fill in for
inter-systems communication of units. However, ISO 2599 and ANSI
X3.50 currently have severe defects:
</p>
<list role="ordered">
<item>
<p>
ISO 2955 and ANSI X3.50 contain numerous name conflicts,
both direct conflicts (e.g., “
<code>a</code>
” being used
for both “year” and “are”) and conflicts
that are generated through combination of unit symbols with prefixes
(e.g., “
<code>cd</code>
” means candela and centi-day and
“
<code>PEV</code>
” means peta-volt and pico-electronvolt.)
</p>
</item>
<item>
<p>
Neither ISO 2955 nor ANSI X3.50 cover all units that are
currently used in practice. There are many more units in use than what
is allowed by the
<emph>Système International
d'Unités</emph>
(SI) and accompanying standards. For example,
the older CGM-units dyne and erg are still used in the science of
physiology. Although ANSI X3.50 extends ISO 2955 with some
U.S. customary units, it is still not complete in this respect. For
example it does not define the degree Fahrenheit.
</p>
</item>
<item>
<p>
ANSI X3.50 is semantically ambiguous with respect to customary
units, even if we do not consider the history and international
aspects of customary units. Three systems of mass units are used in
the U.S., avoirdupois used generally, apothecaries' used by
pharmacists, and troy used in trade with Gold and other precious
metals. ANSI X3.50 has no way to select any one of those
specifically, which is bad in medicine, where both apothecaries' and
avoirdupois weights are being used frequently.
</p>
</item>
</list>
<p>
ISO 2955 and all standards that do only look for the resolutions
and recommendations of the CGPM and the
<emph>Comité
International des Poids et Mesures</emph>
(CIPM) as published by the
<emph>Bureau International des Poids et Mesures</emph>
(BIPM) and various
ISO standards (ISO 1000 and ISO 31) fail to recognize that
the needs in practice are often different from the ideal propositions
of the CGPM. Although not allowed by the CGPM and related ISO
standards, many other units are used in international sciences,
healthcare, engineering, and business, both meaningfully and some
units of questionable meaning. A coding system that is to be useful in
practice must cover the requirements and habits of the
practice—even some of the bad habits.
</p>
<p>
None of the current standards attempt to specify a semantics of units
that can be deployed in information systems with moderate
requirements. Metrological standards such as those published by the
BIPM are dedicated to maximal scientific correctness of reproducible
definitions of units. These definitions make sense only to human
specialists and can hardly be deployed to their full extent by any
information system that is not dedicated to metrology. On the other
hand, ISO 2955 and ANSI X3.50 provide no semantics at all for the
codes they define.
</p>
<p>
<emph>The Unified Code for Units of Measure</emph>
provides a single coding system for units that is complete,
free of all ambiguities, and that assigns to each defined unit a
concise semantics. In communication it is not only important that all
communicating parties have the same repertoir of symbols, but also that
all attach the same meaning to the symbols they exchange. The common
meaning must be computationally verifiable.
<emph>The Unified Code for Units of Measure</emph>
assumes a
semantics for units based on dimensional analysis.
<footnote>
<p>
A more extensive introduction into this semantics of units can be
found in: Schadow G, McDonald CJ et al: Units of Measure in Clinical
Information Systems;
<it>JAMIA</it>
6(2); Mar/Apr 1999;
p. 151–162.
</p>
</footnote>
</p>
<p>
<!-- FIXME this paragraph is a lump: we need Roadmap, scope, etc. -->
In short, each unit is defined relative to a system of base units by a
numeric factor and a vector of exponents by which the base units
contribute to the unit to be defined. Although we can reflect all the
meaning of units covered by dimensional analysis with this vector
notation, the following tables do not show these vectors. One reason
is that the vectors depend on the base system chosen and even on the
ordering of the base units. The other reason is that these vectors are
hard to understand to human readers while they can be easily derived
computationally. Therefore we define new unit symbols using algebraic
terms of other units. Those algebraic terms are also valid codes of
<emph>The Unified Code for Units of Measure</emph>
.
</p>
</div1>
<div1>
<head>Grammar of Units and Unit Terms</head>
<p name="preliminaries">
<emph role="strong">
<anchor id="para-1">§1</anchor>
preliminaries
</emph>
<emph role="strong">
<emph role="sup"> ■1</emph>
</emph>
<emph>The Unified Code for Units of Measure</emph>
consists of a basic set of terminal symbols for units, called
<emph>atomic unit symbols</emph>
or
<emph>unit atoms</emph>
, and multiplier
prefixes. It also consists of an expression syntax by which these
symbols can be combined to yield valid units.
<emph role="strong">
<emph role="sup"> ■2</emph>
</emph>
The tables of terminal symbols are fixed as of every revision of
<emph>The Unified Code for Units of Measure</emph>
, additions, deletions or changes are
<emph>not</emph>
allowed.
<emph role="strong">
<emph role="sup"> ■3</emph>
</emph>
All expression that can be derived from these terminal symbols and the
expression syntax are valid codes. Any expression of
<emph>The Unified Code for Units of Measure</emph>
has a
precisely defined semantics.
</p>
<comment>
<p class="comment">
The expression syntax of
<emph>The Unified Code for Units of Measure</emph>
generates an infinite number of codes
with the consequence that it is impossible to compile a table of all
valid units.
</p>
<p class="comment">
That the tables of terminal symbols may not be extended does not mean
that missing symbols will never be available in
<emph>The Unified Code for Units of Measure</emph>
. Suggestions
for additions of new symbols are welcome and revisions of
<emph>The Unified Code for Units of Measure</emph>
will be released as soon as a change request has been approved.
</p>
</comment>
<p name="full and limited conformance">
<emph role="strong">
<anchor id="para-2">§2</anchor>
full and limited conformance
</emph>
<emph role="strong">
<emph role="sup"> ■1</emph>
</emph>
The semantics of
<emph>The Unified Code for Units of Measure</emph>
implies equivalence classes such that
different expressions may have the same meaning.
<emph role="strong">
<emph role="sup"> ■2</emph>
</emph>
Programs that declare
<emph>full conformance</emph>
with
<emph>The Unified Code for Units of Measure</emph>
must
compare unit expressions by their semantics, i.e. they must detect
equivalence for different expressions with the same meaning.
<emph role="strong">
<emph role="sup"> ■3</emph>
</emph>
Programs with
<emph>limited conformance</emph>
may compare unit expressions
literally and thus may not detect equivalence of unit expressions.
</p>
<comment>
<p class="comment">
The option for “limited conformace” allows
<emph>The Unified Code for Units of Measure</emph>
to be adopted
even by less powerful systems that can not or do not want to deal with
the full semantics of units. Those systems typically have a table of
fixed unit expression literals that may be related to other literals
with fixed conversion factors. Although these systems will have
difficulties to receive unit expressions from various sources, they
will at least send out valid expressions of
<emph>The Unified Code for Units of Measure</emph>
, which is an
important step towards a commonly used coding scheme for units.
</p>
</comment>
<div2>
<head>Character Set and Lexical Rules</head>
<p name="character set">
<emph role="strong">
<anchor id="para-3">§3</anchor>
character set
</emph>
<emph role="strong">
<emph role="sup"> ■1</emph>
</emph>
All expressions of
<emph>The Unified Code for Units of Measure</emph>
shall be built from characters of
the 7-bit US-ASCII character set exclusively.
<emph role="strong">
<emph role="sup"> ■2</emph>
</emph>
Terminal unit symbols can consist of all ASCII characters in
the range of 33–126 (0x21–0x7E) excluding
double quotes (‘
<code>"</code>
’),
parentheses (‘
<code>(</code>
’ and ‘
<code>)</code>
’),
plus sign (‘
<code>+</code>
’'),
minus sign (‘
<code>-</code>
’'),
period (‘
<code>.</code>
’'),
solidus (‘
<code>/</code>
’'),
equal sign (‘
<code>=</code>
’'),
square brackets (‘
<code>[</code>
’
and ‘
<code>]</code>
’), and
curly braces (‘
<code>{</code>
’ and ‘
<code>}</code>
’),
which have special meaning.
<emph role="strong">
<emph role="sup"> ■3</emph>
</emph>
A terminal unit symbol can not consist of only digits
(‘
<code>0</code>
’–‘
<code>9</code>
’) because
those digit strings are interpreted as positive integer
numbers. However, a symbol “
<code>10*</code>
” is allowed
because it ends with a non-digit allowed to be part of a symbol.
<emph role="strong">
<emph role="sup"> ■4</emph>
</emph>
For every terminal symbol there is a case insensitive variant
defined, to be used when there is a risk of upper and lower case to be
confused. Although upper and lower case can be mixed in case
insensitive symbols there is no meaning to the case. Case insensitive
symbols are incompatible to the case senitive symbols.
</p>
<comment>
<p class="comment">
The 7-bit US-ASCII character code is the greatest common denominator
that can be expected to be available in any communication environment.
Only very few units normally require symbols from the greek alphabet
and thus the cost of requiring Unicode does not outweigh the benefit.
As explained above, the real issue about writing unit terms naturally
is not the character set but the ability to write subscripts and
superscripts and distinguish roman letters from italics.
</p>
<p class="comment">
Some computer systems or programming languages still have the
requirement of case insensitivity and some humans who are not familiar
with SI units tend to confuse upper and lower case or can not
interpret the difference in upper and lower case correctly. For this
reason the case insensitive symbols are defined. Although
<emph>The Unified Code for Units of Measure</emph>
does not encourage use of case insensitive symbols where not
absolutely necessary, in some circumstances the case insensitive
representation may be the greatest common denominator. Thus some
systems that can handle case sensitivity may end up using case
insensitive symbols in order to communicate with less powerful
systems.
</p>
<p class="comment">
ISO 2955 and ANSI X3.50 call case sensitive symbols “mixed
case” and case insensitive symbols “single case” and
list two columns for “single case” symbols, one for upper
case and one for lower case. In
<emph>The Unified Code for Units of Measure</emph>
all units can be written in
mixed upper and lower case, but in the case insensitive variant the
mixing of case does not matter.
</p>
<p class="comment">
White space is not recognized in a a unit term and should generally
not occur. UCUM implementations may flag whitespace as an error
rather than ignore it. Whitespace is not used as a separator of
otherwise ambiguous parts of a unit term.
</p>
</comment>
<p name="prefixes">
<emph role="strong">
<anchor id="para-4">§4</anchor>
prefixes
</emph>
<emph role="strong">
<emph role="sup"> ■1</emph>
</emph>
Metric units (cf.
<termref ref="para-11">§11</termref>
) may be
combinations of a unit symbol with a prefix symbol.
<emph role="strong">
<emph role="sup"> ■2</emph>
</emph>
The unit symbol to be combined with the prefix must not itself
contain a prefix. Such a prefix-less unit symbol is called
<emph>unit
atom</emph>
.
<emph role="strong">
<emph role="sup"> ■3</emph>
</emph>
Prefix and atom are connected immediately without any
delimiter. Separation of an optional prefix from the atom occurs on
the lexical level by finding a matching combination of an optional
prefix and a unit atom.
<emph role="strong">
<emph role="sup"> ■4</emph>
</emph>
The prefix is the longest leading substring that matches a
valid prefix where the remainder is a valid metric unit atom. If no
such prefix can be matched, the unit atom is without prefix and may be
both metric or non-metric.
<emph role="small">[1–3: ISO 1000, 3; ISO 2955-1983, 3.7;
ANSI X3.50-1986, 3.7 (Rule No. 6).]</emph>
</p>
<p name="square brackets">
<emph role="strong">
<anchor id="para-5">§5</anchor>
square brackets
</emph>
<emph role="strong">
<emph role="sup"> ■1</emph>
</emph>
Square brackets (‘
<code>[</code>
’ and
‘
<code>]</code>
’) may be part of a
unit atom at any place but only as matched pairs. Square brackets are
lexical elements and not separate syntactical tokens.
<emph role="strong">
<emph role="sup"> ■2</emph>
</emph>
Within a matching pair of square brackets the full range of
characters 33–126 can be used.
<footnote>
<p>
see the section about style in
<termref ref="para-12">§§12ff</termref>
, to find out
how square brackets are actually used. Note, however, that the user
has no choice about square bracket symbols, as these are fixed in the
list of atomic unit symbols.
</p>
</footnote>
<emph role="strong">
<emph role="sup"> ■3</emph>
</emph>
Square brackets do
<emph>not</emph>
determine the boundary between
prefix and unit atom, but they never span the boundary of unit atoms.
<emph role="strong">
<emph role="sup"> ■4</emph>
</emph>
Square brackets must not be nested.
</p>
<comment>
<p class="comment">
For example
%
“
<code>[abc+ef]</code>
”,
“
<code>ab[c+ef]</code>
”,
“
<code>[abc+]ef</code>
”, and
“
<code>ab[c+ef]</code>
”
%
could all be valid symbols if defined in the tables.
In “
<code>ab[c+ef]</code>
” either
“
<code>a</code>
” or “
<code>ab</code>
”
could be defined as a prefix, but not “
<code>ab[c</code>
”.
</p>
<p class="comment">
Square brackets take on one task of round parentheses in HL7's
“ISO+” code, where one use of parentheses is to augment
unit symbols with suffixes, as in “
<code>mm(Hg)</code>
”.
Another use is to enclose one full unit symbol into parentheses, as
“
<code>(ka_u)</code>
” (for the King-Armstrong unit of
catalytic amount of phosphatase). Apparently, in a unit symbol such
enclosed one is supposed not to expect a prefix. Thus, even if
“
<code>a_u</code>
” would have been defined,
“
<code>(ka_u)</code>
” should not be matched against
kilo-
<code>a_u</code>
.
</p>
<p class="comment">
Parentheses, however, were also used for the nesting of terms since
HL7 version 2.3. At this point it became ambiguous whether parentheses
are part of the unit symbol or whether they are syntactic tokens. For
instance, “
<code>(ka_u)</code>
” could mean a nested
“
<code>ka_u</code>
” (where “
<code>k</code>
”
could possibly be a prefix), but also the proper symbol
“
<code>(ka_u)</code>
” that happens to have parentheses as
part of the symbol.
<emph>The Unified Code for Units of Measure</emph>
uses parentheses for the usual meaning of
term nesting and uses square brackets where HL7's “ISO+”
assumes parentheses to be part of the unit symbol.
</p>
</comment>
<p name="curly braces">
<emph role="strong">
<anchor id="para-6">§6</anchor>
curly braces
</emph>
<emph role="strong">
<emph role="sup"> ■1</emph>
</emph>
The full range of characters 33–126 can be used within a
pair of curly braces (‘
<code>{</code>
’ and
‘
<code>}</code>
’). The material enclosed in curly braces is
called
<emph>annotation</emph>
.
<emph role="strong">
<emph role="sup"> ■2</emph>
</emph>
Annotations do not contribute to the semantics of the unit but are
meaningless by definition. Therefore, any fully conformant parser must
discard all annotations. Parsers of limited conformace
<emph>should</emph>
not value annotations in comparison of units.
<emph role="strong">
<emph role="sup"> ■3</emph>
</emph>
Annotations do, however, signify the end of a unit symbol.
<emph role="strong">
<emph role="sup"> ■4</emph>
</emph>
An annotation without a leading symbol implies the default
unit
<unit>1</unit>
(the unity).
<emph role="strong">
<emph role="sup"> ■5</emph>
</emph>
Curly braces must not be nested.
</p>
<comment>
<p class="comment">
Curly braces are here because people want annotations and deeply
believe that they need annotations. Especially in chemistry and
biomedical sciences, there are traditional habits to write annotations
at units or instead of units, such as “%vol.”,
“RBC”, “CFU”, “kg(wet tis.)”, or
“mL(total)”. These habits are hard to overcome. Any
attempt of a coding scheme to restrict this percieved expressiveness
will ultimately result in the coding scheme not being adopted, or just
“half-way” adopted (which is as bad as not adopted).
</p>
<p class="comment">
Two alternative responses to this reality exist: either give in to the
bad habits and blow up of the code with dimension- and meaningless
unit atoms, or canalize this habit so that it does no harm.
<emph>The Unified Code for Units of Measure</emph>
canalizes this habit using curly braces. Nevertheless we do continuing
efforts to upgrade doubtful units to genuine units of
<emph>The Unified Code for Units of Measure</emph>
by
defining and linking them to the other units as good as
possible. Thus, “
<code>g%</code>
” is a valid metric unit
atom (so that “
<code>mg%</code>
” is a valid unit too.)
A
<emph>drops</emph>
, although quite imprecise, is a valid unit of volume
“
<code>[drp]</code>
”. Even HPF and LPF (the so called
“high-” and “low power field” in the
microscope) have been defined so that at least they relate to each
other.
</p>
</comment>
</div2>
<div2>
<head>Syntax Rules</head>
<p name="algebraic unit terms">
<emph role="strong">
<anchor id="para-7">§7</anchor>
algebraic unit terms
</emph>
<emph role="strong">
<emph role="sup"> ■1</emph>
</emph>
All units can be combined in an algebraic term using the
operators for multiplication (period ‘
<code>.</code>
‘) and
division (solidus ‘
<code>/</code>
’).
<emph role="strong">
<emph role="sup"> ■2</emph>
</emph>
The multiplication operator is mandatory it must not be
omitted or replaced by a space. The multiplication operator is a
strict binary operator that may occur only
<emph>between two</emph>
unit
terms.
<emph role="strong">
<emph role="sup"> ■3</emph>
</emph>
The division operator can be used as a binary and unary
operator, i.e. a leading solidus will invert the unit that directly
follows it.
<emph role="strong">
<emph role="sup"> ■4</emph>
</emph>
Terms are evaluated from left to right with the period and the
solidus having the same operator precedence. Multiple division
operators are allowed within one term.
<emph role="small">[ISO 1000, 4.5.2; ISO 2955-1983, 3.3f; ANSI X3.50-1986, 3.3f
(Rule No. 2f).]</emph>
</p>
<comment>
<p class="comment">
The use of the period instead of the asterisk
(‘
<code>*</code>
’) as a multiplication operator continues a
tradition codified in ISO 1000 and maintained in ISO 2955. Because
floating point numbers may not occur in unit terms the period is not
ambiguous. A period in a unit term has no other meaning than to be the
multiplication operator.
</p>
<p class="comment">
Since Resolution 7 of the 9th CGPM in 1948 the myth of ambiguity being
introduced by more than one solidus lives on and is quoted in all
standards concerning the writing of SI units. However, when the strict
left to right rule is followed there is no ambiguity, neither with one
solidus nor with more than one solidus. However, in human practice we
find the tendency to assign a lower precedence to the solidus which
misleads people to write
<emph>a</emph>
/
<emph>b</emph>
·
<emph>c</emph>
when they
really mean
<emph>a</emph>
/(
<emph>b</emph>
·
<emph>c</emph>
). When this is
rewritten as
<emph>a</emph>
/
<emph>b</emph>
/
<emph>c</emph>
there is actually less
ambiguity that in
<emph>a</emph>
/
<emph>b</emph>
·
<emph>c</emph>
. So the real
source of ambiguity is when a multiplication operator follows a
solidus, not when there is more than one solidus in a term. Hence, we
remove the restriction for only one solidus and introduce parentheses
which may be used to remove any perceived ambiguity.
</p>
</comment>
<p name="integer numbers">
<emph role="strong">
<anchor id="para-8">§8</anchor>
integer numbers
</emph>
<emph role="strong">
<emph role="sup"> ■1</emph>
</emph>
A positive integer number may appear in place of a simple unit
symbol.
<emph role="strong">
<emph role="sup"> ■2</emph>
</emph>
Only a pure string of decimal digits
(‘
<code>0</code>
’–‘
<code>9</code>
’)
is interpreted as a number. If after one or more digits there is any
non-digit character found that is valid for unit atoms, all the
characters (including the digits) will be interpreted as a simple unit
symbol.
</p>
<comment>
<p class="comment">
For example, the string “
<code>123</code>
” is a positive
integer number while “
<code>12a</code>
” is a symbol.
</p>
<p class="comment">
Note that the period is only used as a multiplication operator, thus
“
<code>2.5</code>
” means 2 × 5 and is not equal to 5/2.
</p>
</comment>
<p name="exponents">
<emph role="strong">
<anchor id="para-9">§9</anchor>
exponents
</emph>
<emph role="strong">
<emph role="sup"> ■1</emph>
</emph>
Simple units may be raised to a power. The exponent is an
integer number and is written immediately behind the unit
term. Negative exponents must be preceded by a minus sign
(‘
<code>-</code>
’ positive exponents may be preceded by an
optional plus sign (‘
<code>+</code>
’).
<emph role="strong">
<emph role="sup"> ■2</emph>
</emph>
If the simple unit raised to a power is a combination of a
prefix and a unit atom, both are raised to the power, e.g. “1
<code>cm3</code>
” equals “10
<emph role="sup">-6</emph>
<code>m3</code>
” not “10
<emph role="sup">-2</emph>
<code>m3</code>
”.
<emph role="small">[ISO 2955-1983, 3.5f; ANSI X3.50-1986, 3.5f (Rule
No. 4f).]</emph>
</p>
<comment>
<p class="comment">
ISO 2955 and ANSI X3.50 actually do not allow a plus sign leading a
positive exponent. However, if there can be any perceived ambiguities,
an explicit leading plus sign may be of help sometimes.
<emph>The
Unified Code for Units of Measures</emph>
therefore allows such plus signs
at exponents. The plus sign on positive exponents can be used to
delimit exponents from integer numbers used as simple units. Thus,
<code>2+10</code>
means 2
<emph role="sup">10</emph>
= 1024.
</p>
</comment>
<p name="nested terms">
<emph role="strong">
<anchor id="para-10">§10</anchor>
nested terms
</emph>
<emph role="strong">
<emph role="sup"> ■1</emph>
</emph>
Unit terms with operators may be enclosed in parentheses
(‘
<code>(</code>
’ and ‘
<code>)</code>
’) and used
in place of simple units. Normal left-to-right evaluation can be
overridden with parentheses.
<emph role="strong">
<emph role="sup"> ■2</emph>
</emph>
Parenthesized terms are
<emph>not</emph>
considered unit atoms
and hence must not be preceded by a prefix.
</p>
<comment>
<p class="comment">
Up until revision 1.9 there was a third clause
“Since a unit term in parenthesis can be used in place of
a simple unit, an exponent may follow on a closing parenthesis which
raises the whole term within the parentheses to the power.”
However this feature was inconsistent with any BNF or other syntax
description ever provided, was never used and seems to have no
relevant use case. For this reason this clause has been stricken.
This is a
<emph>tentative</emph>
change. Users who have used this
feature in the past, should please comment on this deprecation.
If we receive indication that this feature was used by anyone, we
would undo the deprecation. If no comments are received, the
deprecation continues to take effect.
</p>
</comment>
<exhibit role="exhibit">
<table class="plain" border="0">
<tr valign="top">
<td>
<
<emph>sign</emph>
>
</td>
<td>::=</td>
<td>
“
<code>+</code>
” | “
<code>-</code>
”
</td>
</tr>
<tr valign="top">
<td>
<
<emph>digit</emph>
>
</td>
<td>::=</td>
<td>
“
<code>0</code>
” | “
<code>1</code>
” | “
<code>2</code>
” |
“