|
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 dlee@calldei.com http://www.calldei.com http://www.xmlsh.org From: Gregory Alvord
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----- 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 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 |