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).
I am implementing some of the versioned document
semantics and have a quick query.
VERSIONED_OBJECT 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 is a particular instance of a
document version - so many VERSION
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:
Change the type of object_id attribute of OBJECT_VERSION_ID from UID to HIER_OBJECT_ID (probably the easiest thing to do)
or
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 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't really think of any other way a VERSIONED_OBJECT
would be created?)
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.
I am implementing some of the versioned document
semantics and have a quick query.
VERSIONED_OBJECT 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 is a particular instance of a
document version - so many VERSION
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:
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).
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)?
The VERSIONED_OBJECT class does not exist in the openEHR XML schema as it is a functional class. Therefore it only affects X_VERSIONED_OBJECT in the draft Extract.xsd.
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.