On Sat, 7 Jul 2001, Richard Knapp wrote:
> Date: Sat, 07 Jul 2001 05:57:06 -0400 (EDT)
> From: Richard Knapp <gyp_caver@yahoo.com>
> Reply-To: cavexml@cartography.ch
> To: "cavexml@cartography.ch" <cavexml@cartography.ch>
> Subject: Re: ID specification?
>
> On Fri, 6 Jul 2001 11:14:48 -0600 (MDT), John Halleck wrote:
>
> >> > [... Unique Record ID's ...]
> >
> >> > >http://rubens.its.unimelb.edu.au/~pgm/uisic/exchange/exchprop.html
> >
> > "nnnnn
> > a numeric serial number, being an agreed fixed length for a given
> > entity, and padded left with zeros. Unique within a given aa and
> > bbb. See Entity List below for
> > "
> > Making the number field a fixed size puts in assumptions about sizes.
> >
> > Why do this? (I.E. I don't see any advantage to this, and there are
> > obvious problems with it, so I think I missed something.)
>
> I've always like a combination of numbers and characters for keys (ie. "A134BC"). The code is pretty simple to write but it
> increases the keys for a given fixed size rather considerably! If the key was 3 digits long, there are then 46656 possible
But (Ala IOS oid's) a syntaticly delimited field need not have a fixed size limit.
("FOO.123.B" style instead of "FOO123B" style) when one can identify field limits
issues like sorting (brought up on the page) are moot and can be handled in the
LDAP fashion.
> combinations instead of 1000. I like to limit it to upper case to keep things a little simpler but lower case could be brought in
> too.
Upper and lower case makes lots of assumptions about the underlying character sets.
The discussions in international standards about using UTF-8 (or other Unicode)
encoding is all relivant to the discussion, but I'll not repeat here.
>
>
> - Richard Knapp
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
This archive was generated by hypermail 2b30 : Mon Sep 03 2001 - 06:00:00 CEST