OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Should information be encoded into identifiers?

I could argue there are cases where its perfectly OK for ID's to change in an object.
It all depends on what you use the ID's for.  And what scope they need to be valid.
An example, Filenames ...
Renaming a file (changing its "ID") is perfectly common and usually harmless and often useful.
( Its debatable in the document community if "Save As" generates a NEW document or simply duplicates an existing one).
Sticking to a hard rule that ID's cant change isnt always pragmatic.
It depends on what they are used for ...
My phone number and email address change from time to time.
Sometimes I wish I could change my SS# ... !
The GUID's mentioned are an interesting diversion.  The fact they contain a timestamp and a MAC address I think are not the important issue.
The important issue of GUID's is to guarentee that no 2 GUID's are ever created, even if done simultaneously across the world.
That’s often a goal if ID's,  uniqueness ... sometimes that trumps usefulness.
But the you cant generate the same GUID twice even if on the same object.
That can be as bad as good.
David A. Lee

Sent: Friday, March 05, 2010 7:09 PM
Subject: RE: [xml-dev] Should information be encoded into identifiers?

In two of the three cases you mention the encoded data binds to a physical object or a collection of physical objects.


In the third case the encoded data is a time stamp.


What is common in all these cases is after assignment if the ID is NEVER EVER changes.


Meeting that condition in most systems is very hard. I have had conversations like this dozens of times


Wouldn’t it be cool to have the Region of the salesmen encoded in his ID?

Sure, but what happens when he move to a different region?

Do we change the ID of the salesmen and orphan all his old records?

Or do we keep his old ID which makes the region encoding a lie?


Encoding data into ID violates one of Dr. Codd’s design rules. It makes the key a functionally related to other facts in the record.


Vet very carefully any proposal to have encoding in ID values.  If the business representatives cannot swear a blood oath that the encoded fact will never change use something else.


-----Original Message-----
From: Costello, Roger L. [mailto:costello@mitre.org]
Sent: Friday, March 05, 2010 3:58 PM
To: xml-dev@lists.xml.org
Subject: [xml-dev] 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?




[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]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS