EbRIM/identifiers: Difference between revisions
Jump to navigation
Jump to search
New page: Every RegistryObject is a persistent identifiable object. Being persistent means it can be stored and later retrieved. Being identifiable means it has a permanent... |
No edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
Every [[ebRIM/RegistryObject|RegistryObject]] is a | Every [[ebRIM/RegistryObject|RegistryObject]] is a persistable identifiable object. Being persistable means it can be stored and later retrieved. Being identifiable means it has a permanent id which can be used to address it. In XML this permanent id is the ''id'' attribute: | ||
<ExtrinsicObject | <ExtrinsicObject id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d" ... | ||
in XD* documentation it is known as entryUUID. | |||
This identifier takes on two forms: UUID and symbolic. In the original OASIS context the universe consists of an integrated Registry/Repository. In this context, ids must be in UUID form before being committed to the database backing the Registry. As a result a Stored Query response will always contain ids in UUID form. | |||
Latest revision as of 11:22, 24 December 2010
Every RegistryObject is a persistable identifiable object. Being persistable means it can be stored and later retrieved. Being identifiable means it has a permanent id which can be used to address it. In XML this permanent id is the id attribute:
<ExtrinsicObject id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d" ...
in XD* documentation it is known as entryUUID.
This identifier takes on two forms: UUID and symbolic. In the original OASIS context the universe consists of an integrated Registry/Repository. In this context, ids must be in UUID form before being committed to the database backing the Registry. As a result a Stored Query response will always contain ids in UUID form.