[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Should information be encoded into identifiers?

  • From: "David Lee" <dlee@calldei.com>
  • To: "Costello, Roger L." <costello@mitre.org>, <xml-dev@l...>
  • Date: Fri, 5 Mar 2010 17:17:16 -0500

Re:  Should information be encoded into identifiers?
Excellent question.   I have a few opinions related to vast failures in my 
past :)
I have found that having symbolic identifiers is much preferable to purely 
numeric (or seemingly random) identifiers.
The reasons are both human and programatic.

Human reasons
If an identifier has human readable meaning then the chance of it being 
confused is less.
This is a big problem with versioning and merging.   Suppose you have a 
catalog system of stuff (say books),
and you number then 1,2,3 ... 99934315 ... Then do a backup.
Then you add more books ... and delete some.    Supose multiple systems are 
doing this.
Then you want to merge 2 datasets, either a backup + current, or 2 peoples 
datasets.
If you use purely numeric system its very hard to tell if "55314" in set 1 
is the "same thing" as "55314" in set 2.
Wheras if you have "Joes_Random_Amusements" and "Joes_Random_Amusements" 
from 2 different sets, the chances of them being
"the same thing" is much higher.   Why ?  From a computer perspective in 
both caes the string is an exact match,
but from a human perspective if the ID has some meaning in it, its easier to 
tell if it's the same thing.

This leads me to belive that whenever possible ID's should both be strings, 
and have meaning.

Programmatic Reasons
Similar to human reasons.  If you encode meaning into an ID, it is ideal if 
the generation of that ID is reproducible without state.
That is, without a central catalog dishing out ID's.    Take your ISDN 
numbers ( or MAC addresses).   Because they segment the ID
into company portions, its possible for each company to assign meaning to 
the ID's ... and ideally if they have to re-generate an ID
from 'the same thing' it should produce the same ID.
This is not always possible but it is a goal.
If you can possibly generate an ID reproducibly from the object that is an 
ideal case.  If not, then if you can generate an ID that a human can 
recognize as likely representing that object that is good.


There's other reasons too ... but I'll stop while I'm behind.





----------------------------------------------------
David A. Lee
dlee@calldei.com
http://www.calldei.com
http://www.xmlsh.org


--------------------------------------------------
From: "Costello, Roger L." <costello@mitre.org>
Sent: Friday, March 05, 2010 4:57 PM
To: <xml-dev@lists.xml.org>
Subject:  Should information be encoded into identifiers?

> Hi Folks,
>
> Should identifiers be dumb? That is, no meaning can be ascribed to 
> identifiers; they are completely random.
>
> Or, should information be encoded into identifiers? What information 
> should be encoded into them?
>
> There are precedents for encoding information into identifiers:
>
> 1. In the U.S. each auto is identified by a Vehicle Identification Number 
> (VIN). Encoded within each VIN is a wealth of information, including the 
> make and model of the auto, the plant where it was manufactured, and the 
> vehicle's options.[1]
>
> 2. Books are identified by ISBNs. Encoded within each ISBN is a wealth of 
> information, including the country, publisher, and the relative size of 
> the publisher.[2]
>
> 3. UUIDs are used in many applications. Encoded within some UUIDs are the 
> date/time stamp of when the UUID was created, and the network address of 
> the machine which created the UUID.[3]
>
> I suspect there are other examples of identifiers that have information 
> encoded into them.
>
> What are the advantages of encoding information into an identifier? What 
> are the disadvantages?
>
> /Roger
>
> [1] Format of VIN: http://en.wikipedia.org/wiki/VIN
>
> [2] Format of ISBN: http://www.xfront.com/isbn.xsd
>
> [3] Fomat of UUID: http://www.ietf.org/rfc/rfc4122.txt
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.