[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue 3: (STANDARD_MEASURES)
>Issue 3: (STANDARD_MEASURES)
>
>Should we restrict registrations to either metric or imperial
>measures? Current proposal is to allow either measuring system to be
>registered, but to require those registering the same thing in a
>second system to provide a conversion that other systems can reliably
>use to convert. This means not only providing a numeric conversion,
>but a rounding convention for use in contexts where only whole
>integers are provided.
This has potential to get messy, I think.
I'd go with the need to indicate allowed units in the feature registration.
But I think we also need to indicate a standard way for designating units
in protocol elements (What is default unit? How are alternatives indicated?)
I think this is going to be important when it comes to actually
implementing interoperable protocol processors that handle units.
For example, taking the issue of paper size measured in Inches, Millimetres
or Metres. I suggest that the measurements are of the form:
<number> [ "in" | "mm" | "m" ]
where the default is "m". (I would argue for use of SI units as default in
all cases.)
Another example, image resolutions in dpi, dpcm, dpm:
<number> [ "/" ( "in" | "cm" | "m" ) ]
The above notation is consistent with use of juxtaposition as
multiplication, "/" as division and unit designators simply being constants
for conversion from the named unit to SI. Thus, this provides a consistent
framework which can extend to any measurement type. And a consistent
interpretation (i.e. SI) in the absence of a unit designation.
(I believe there was some programming language work which explored the use
of unit designators in this way, but I cannot recall any references.)
A number of such units might be defined in the registration document, so
that the introduction of new units in individual feature registrations is
an exception rather than norm:
Length: in, ft, pt, mm, cm, m
Area: sqin, sqft, sqmm sqcm, sqm
Mass: lb, g, kg
:
BTW, I think that it may be advisable to reserve unit names so that they
cannot be allocated as non-faceted feature tags (i.e. in the IETF tree).
#g
------------
Graham Klyne