# VERSIONED_OBJECT<T> uid question

**Category:** [Implementers (archive)](https://discourse.openehr.org/c/implementers-archive/158)
**Created:** 2008-09-10 01:49 UTC
**Views:** 1
**Replies:** 6
**URL:** https://discourse.openehr.org/t/versioned-object-t-uid-question/14812

---

## Post #1 by @Andrew_Patterson

Hi all,

I am implementing some of the versioned document
semantics and have a quick query\.

VERSIONED\_OBJECT&lt;T&gt; has a &#39;uid&#39; attribute
that is meant to represent a unique identifier
for all versions of this object \- so kind of like
the master identifier for this document set\.
It is of type HIER\_OBJECT\_ID

VERSION&lt;T&gt; is a particular instance of a
document version \- so many VERSION&lt;T&gt;
documents may be part of one overall
VERSIONED\_OBJECT \(amendments etc\)\.
It also has a &#39;uid&#39; attribute of type
OBJECT\_VERSION\_ID\.

A OBJECT\_VERSION\_ID consists of
object\_id, version\_tree\_id and creating\_system\_id\.
Section 6\.3\.3 says that the object\_id
part is a copy of the uid attribute of
VERSIONED\_OBJECT\. However, this doesn&#39;t
really work because VERSIONED\_OBJECT has
a uid which is a HIER\_OBJECT\_ID \(could be in the form
1\.23\.4\.5\.6\.4::abcd\), whereas object\_id can only
be a plan UID \(i\.e\. 1\.23\.4\.5\.6\.4\)\.

Andrew

---

## Post #2 by @system

> Hi all,
>
> I am implementing some of the versioned document
> semantics and have a quick query.
>
> VERSIONED_OBJECT<T> has a 'uid' attribute
> that is meant to represent a unique identifier
> for all versions of this object - so kind of like
> the master identifier for this document set.
> It is of type HIER_OBJECT_ID
>
> VERSION<T> is a particular instance of a
> document version - so many VERSION<T>
> documents may be part of one overall
> VERSIONED_OBJECT (amendments etc).
> It also has a 'uid' attribute of type
> OBJECT_VERSION_ID.
>
> A OBJECT_VERSION_ID consists of
> object_id, version_tree_id and creating_system_id.
> Section 6.3.3 says that the object_id
> part is a copy of the uid attribute of
> VERSIONED_OBJECT. However, this doesn't
> really work because VERSIONED_OBJECT has
> a uid which is a HIER_OBJECT_ID (could be in the form
> 1.23.4.5.6.4::abcd), whereas object_id can only
> be a plan UID (i.e. 1.23.4.5.6.4).

Hi Andrew,

I agree with your analysis. The optional extension part of the HIER_OBJECT_ID will get lost through the owner_id function on VERSION thus breaking the invariant on owner_id_valid. However the issue will not reveal itself if the UID from the first version is used to create VERSIONED_OBJECT.uid since a plain UID can be used to create a perfect HIER_OBJECT_ID without an extension value.

Two possible solutions to this issue:
1. Change the type of object_id attribute of OBJECT_VERSION_ID from UID to HIER_OBJECT_ID (probably the easiest thing to do)
or
2. Use plain UID instead of HIER_OBJECT_ID for uid attribute of VERSIONED_OBJECT (this really depends on why we need extension value for VERSIONED_OBJECT.uid, does anyone have any good examples?)

I created a JIRA issue for this, [http://www.openehr.org/issues/browse/SPEC-278](http://www.openehr.org/issues/browse/SPEC-278)

Cheers,
Rong

---

## Post #3 by @Andrew_Patterson

> I agree with your analysis\. The optional extension part of the
> HIER\_OBJECT\_ID will get lost through the owner\_id function on VERSION thus
> breaking the invariant on owner\_id\_valid\. However the issue will not reveal
> itself if the UID from the first version is used to create
> VERSIONED\_OBJECT\.uid since a plain UID can be used to create a perfect
> HIER\_OBJECT\_ID without an extension value\.

Agreed \- I think the problem will not manifest itself because
the VERSIONED\_OBJECT uid will be derived from
the object\_id of the first version committed into the system
\(I can&#39;t really think of any other way a VERSIONED\_OBJECT
would be created?\)

Andrew

---

## Post #4 by @Heath_Frankel3

Andrew and Rong,

We only use GUIDs (UUID) for HIER_OBJECT_Ids hence have not had any issues. We have also accepted instances using OIDs without an extension with no problems. I would not see why a GUID would have an extension nor do I see an extension being used with a INTERNET_ID. So I guess it is only in the case of OIDs that might be tempting to use an extension.

Regarding Rong’s suggested solutions, I have no problem with solution 1. Solution 2 will cause a significant change to the XML schema as the UID will now need to be a serializable type (i.e. a new complex type for UID will need to be added to the schema) so that it can be used in X_VERSIONED_OBJECT (Extract.xsd) assuming it follows a similar signature to VERSIONED_OBJECT as it currently does.

Heath

---

## Post #5 by @thomas.beale

Rong Chen wrote:

>
> > Hi all,
> >
> > I am implementing some of the versioned document
> > semantics and have a quick query.
> >
> > VERSIONED_OBJECT<T> has a 'uid' attribute
> > that is meant to represent a unique identifier
> > for all versions of this object - so kind of like
> > the master identifier for this document set.
> > It is of type HIER_OBJECT_ID
> >
> > VERSION<T> is a particular instance of a
> > document version - so many VERSION<T>
> > documents may be part of one overall
> > VERSIONED_OBJECT (amendments etc).
> > It also has a 'uid' attribute of type
> > OBJECT_VERSION_ID.
> >
> > A OBJECT_VERSION_ID consists of
> > object_id, version_tree_id and creating_system_id.
> > Section 6.3.3 says that the object_id
> > part is a copy of the uid attribute of
> > VERSIONED_OBJECT. However, this doesn't
> > really work because VERSIONED_OBJECT has
> > a uid which is a HIER_OBJECT_ID (could be in the form
> > 1.23.4.5.6.4::abcd), whereas object_id can only
> > be a plan UID (i.e. 1.23.4.5.6.4).
>
> Hi Andrew,
>
> I agree with your analysis. The optional extension part of the HIER_OBJECT_ID will get lost through the owner_id function on VERSION thus breaking the invariant on owner_id_valid. However the issue will not reveal itself if the UID from the first version is used to create VERSIONED_OBJECT.uid since a plain UID can be used to create a perfect HIER_OBJECT_ID without an extension value.
>
> Two possible solutions to this issue:
> 1. Change the type of object_id attribute of OBJECT_VERSION_ID from UID to HIER_OBJECT_ID (probably the easiest thing to do)
> or

the problem with this is that OBJECT_VERSION_ID is a subtype of UID_BASED_ID, and its extension (function inherited from the latter) should evaluate to the version_tree_id + creating_system_id parts; and the root (also an inherited function) should evaluate to a pure UID (OID, GUID etc).

> 2. Use plain UID instead of HIER_OBJECT_ID for uid attribute of VERSIONED_OBJECT (this really depends on why we need extension value for VERSIONED_OBJECT.uid, does anyone have any good examples?)

logically this would make more sense. I will have to search into the older CRs to see why we used HIER_OBJECT_ID instead of UID - I have a feeling this was changed in the past. I think it is linke to why we have UID_BASED_ID as the type of LOCATABLE.uid rather than just UID.

Heath - the schema problem you are talking about - would this affect any existing data except in openEHR Extracts (which is draft, and only we have implemented)?

- thomas

---

## Post #6 by @Heath_Frankel3

Tom,

The VERSIONED_OBJECT<T> class does not exist in the openEHR XML schema as it is a functional class. Therefore it only affects X_VERSIONED_OBJECT<T> in the draft Extract.xsd.

Heath

---

## Post #7 by @thomas.beale

Heath Frankel wrote:
>
> Tom,
>
> The VERSIONED\_OBJECT&lt;T&gt; class does not exist in the openEHR XML schema
> as it is a functional class\.  Therefore it only affects
> X\_VERSIONED\_OBJECT&lt;T&gt; in the draft Extract\.xsd\.
>

\*ok\.\.\.\.that&#39;s what I thought\.

\- thomas

---


**Canonical:** https://discourse.openehr.org/t/versioned-object-t-uid-question/14812
**Original content:** https://discourse.openehr.org/t/versioned-object-t-uid-question/14812