In article <telecom24.70.4@telecom-digest.org>, AES
<siegman@stanford.edu> wrote:
> I've just encountered an annoying hassle where proper handling of
> archival bibliographic data requires keeping track of leading zeros in
> ID numbers; and these seem like informed groups to ask if anyone has
> comments or observations on other electronic or online systems that
> require or even allow leading zeros?
> Specifically the Am Phys Soc now identifies articles not by volume and
> page numbers but by volume and a six-digit "article number" which
> sometimes does and sometimes does not have an initial zero -- but if
> it does you _must_ keep it for various bibliographic and online
> citations to work properly. A few quick tests show that the default
> behavior is to automatically and irretrievably discard leading zeros
> on integer numbers keyed into an Excel worksheet cell or a Mathematic
> list.
Note: *BAD* test.
You can select the 'formatting' on a cell, column, or entire
worksheet, to display numbers with leading zeroes. If you treat the
cell data as a 'number', it will be 'left filled' with zeroes to the
number of positions you specify.
If you treat the cell as *TEXT* then _exactly_ what you enter =will=
be preserved.
> One of my bank accounts prints my account number with three
> leading zeros, but won't accept them in the Account Number field for
> online login. On the other hand for another ID card I have, you
> _must_ type the leading zeros.
> Are there any kind of published refs or computer standards or human
> interface guidelines on the use of leading zeros? ZIP codes use 'em,
> phone numbers don't?
Finding "formal documentation" on this matter is going to be _very_
difficult. Just for starters, "a number is a number is a number" is
simply *NOT* true. Sometimes a "number" is just a "label", not a
'count of a quantity'.
If you can find it, get a copy of the big user-manual for "SPSS" (the
social-science statistics package) They devote a fair amount of the
first _chapter_ to the different "kinds" of numbers -- they identify
at least *five* separate, _incompatible_ types, BTW.
For "counting numbers" -- those on which you can do arithmetic,
leading zeroes are 'immaterial'; can be 'ignored' on input, and are
_commonly_ (although *not* always) "suppressed" on output. The output
suppression _is_ strictly for improved "readability" for/by "humans".
Where the "number" is merely some form of 'label', all bets are off.
The number of symbols in the string _may_ be significant -- in which
case, obviously stripping/inserting 'leading zeroes' *does* change the
label.
Or, the 'number' is a "structured" label. composed of various
(possibly variable-sized) sub-fields. leading zeroes in _any_
sub-field must be preserved, so that the sub-field is the *size*
expected/indicated.
The "safest" thing to do with anything other than 'counting numbers'
is to treat them as 'text strings", which you store, and reproduce,
*exactly* as entered. Well, trimming leading/trailing "white-space"
is allowed, *if* you know that said white-space is *not* significant.
And, of course, any 'validation' that you can do _before_ accepting
the input -- such as no white-space _within_ the 'label' is still OK.
Treating a 'label' as a 'counting number' *IS* a _very_ common
database design error, and one that ends up biting a _lot_ of
inexperienced designers at a 'much later date'. And, when that _does_
happen, it is *really* messy to 'repair' the previously entered data.
Robert Bonomi (bonomi@host122.r-bonomi.com)