Confusing naming in VERSION.uid definition in common_im specs

Description

There aer two definitions for VERSION.uid field:

*owner_id*, creating_system_id and version_tree_id, or
*object_id*, creating_system_id and version_tree_id

What's the right one?

VERSION.uid class definition:
Unique identifier of this version, containing
*owner_id*, creating_system_id and version_tree_id.

section 6.3.3
... a uid attribute, which is a three-part identifier consisting of the
attributes *object_id*, creating_system_id and version_tree_id ...

section 6.3.3 Distributed versioning
... In summary, this scheme uses the tuple {*owner_id*, creating_system_id, version_tree_id} to globally
uniquely identify any openEHR VERSION object.

section 6.5.2 ... Unique identifier of this version, containing
*owner_id*, creating_system_id and version_tree_id.

Environment

None

Activity

Show:
Heath Frankel
May 19, 2015, 11:20 PM

That is a breaking change if you are suggesting to change the name of the OBJECT_VERSION_ID object_id attribute specified in the support IM section 4.3.8.
I would not support that.

Pablo Pazos
May 20, 2015, 12:08 AM

OBJECT_VERSION_ID.object_id is a method not an attribute.

I agree the change would break the interface, but not the internal representation stored on OBJECT_ID.value.

@Heath are you rejecting just because the breaking change? Maybe we need to break something here and there to make it better. IMO that will not affect current implementations because those will be compliant against 1.0.2. If we are going to be 1.0.3 or 2.0 compliant we know we'll need to do some refactoring.

Heath Frankel
May 20, 2015, 12:38 AM

@pablo, sorry you are correct but either way this function is written into how many implementations, we shouldn't just go changing the name of it.

The use of owner_id in the common_im is only descriptive and doesn't affect any interface, it has been aligned in some places but not others. These others should be aligned with the class description in the support IM.

Thomas Beale
May 20, 2015, 6:55 AM

no not suggesting any model change, I assumed the problem was in the spec text only.

Thomas Beale
October 9, 2015, 9:48 AM

Ok, I've reviewed this properly now, and the error in the spec is pretty clear. Let's review:

VERSIONED_OBJECT has properties:

  • uid: HIER_OBJECT_ID – unique id of this object

  • owner_id: OBJECT_REF - the id of the owning EHR or Extract

VERSION

  • uid: OBJECT_VERSION_ID – 3-part id

  • owner_id: unique id of VERSIONED_OBJECT

the confusion has arisen because the documentation for VERSION.uid says it consists of owner_id, version_tree_id and creating_system_id. Here, 'owner_id' means 'owner_id' of the VERSION (i.e the current object), whose value is a VERSIONED_OBJECT.uid (not the VERSIONED_OBJECT's owner_id).

So the value of the field is clear: it consists of the triple {owning VERSIONED_OBJECT.uid, version_tree_id, creating_system_id}. I have documented this in a few places as {object_id, version_tree_id, creating_system_id}, but the text is very clear about what the value of this field is - e.g. read http://www.openehr.org/releases/RM/latest/docs/common/common.html#_version_identification carefully.

I've improved the documentation in this section so it is crystal clear. There are no changes in semantics or naming anywhere.

In a future non-patch release of openEHR, I would be inclined to change various id fields to just be GUIDs, and to simplify the id types.

Reporter

Pablo Pazos

Labels

None

Components

Affects versions

Priority

Trivial
Configure