There was a request from some time ago from Heath Frankel that I now
just dealing with, in the Identification package of the Support IM - see
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/support_im.pdf
The request is to make OBJECT_VERSION_ID a subtype of HIER_OBJECT_ID.
The latter type is the general type for Ids based on a UID of some kind,
possibly with an extension. The former type is a specific type based on
a UID, whose extension happens to be the version_tree_id +
creating_system_id. For some reason I did not think to make this a
subtype of HIER_OBJECT_ID at the time of modelling.
One place where this would help is in LOCATABLE.uid, currently of type
HIER_OBJECT_ID. A related CR is that the uid of top-level objects in
openEHR (Composition, EHR_access, EHR_status, Folder, Party etc) should
carry the uid of their version, i.e. Version.uid
(rm.common.change_control). The point of this is that if you receive say
an XML of a Composition, the uid at the top will be the uid of the
Version, i.e. an OBJECT_VERSION_ID, giving not only the Guid of the
Version container (common to all Compositions that are in a version
set), but also the version_tree_id + creating_system_id extension,
telling us that it is version 4 created in Royal Leeds Infirmary for
example.
I think that the change to make OBJECT_VERSION_ID a subtype of
HIER_OBJECT_ID is sensible on general principle anyway (it means that an
OBJECT_VERSION_ID can be used wherever HIER_OBJECT_ID is specified). I
also think that specifying/recommending the uid at the top of an
top-level object to be its OBJECT_VERSION_ID is sensible, but we can
treat this as a separate change (probably just a recommendation at this
stage). Doing the subtype change means that the functions of each class
behave sensibly, and is easy to do (it is obvious what to do on inspection).
reactions?
- thomas beale
top-level object to be its OBJECT_VERSION_ID is sensible, but we can
treat this as a separate change (probably just a recommendation at this
stage). Doing the subtype change means that the functions of each class
behave sensibly, and is easy to do (it is obvious what to do on inspection).
reactions?
no problems here - I presume that 'extension' for a OBJECT_VERSION_ID
returns creating_system::version_tree as a string, and 'has_extension'
is always true?
Andrew
I have made a CR for this change:
http://coruscant.chime.ucl.ac.uk:8200/openEHR_Collector/projects/specifications/CR/239
and actually carried out the change. I have uploaded the Support IM -
see
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/support_im.pdf
Note that I have done this in a slightly different way to my previous
email proposal.
I have also done the change to the Common IM - LOCATABLE.uid is now of
type UID_BASED_ID.
The only thing I don't really like about the change is the new class
name, but I could not think of anything better. Any suggestions welcome.
There are also many other textual improvements in the Support document.
I would appreciate anyone who wants to give it a close read providing
feedback.
thanks
- thomas
Andrew Patterson wrote:
Tom,
I don't understand why you can't just have OBJECT_VERSION_ID inherit from
HIER_OBJECT_ID. This goes for why GENERIC_ID is required and not just make
OBJECT_ID concrete, but we have been there before. Do you have a principle
that concrete classes must only inherit abstract classes? This results in
more classes in the model and you have problems with naming them. Now
GENERIC_ID has a scheme attribute which is not used in the other siblings so
that makes sense, but HIER_OBJECT_ID adds no features over the UID_BASED_ID
except being concrete.
Heath
Heath Frankel wrote:
Tom,
I don't understand why you can't just have OBJECT_VERSION_ID inherit from
HIER_OBJECT_ID.
because in many places where HIER_OBJECT_ID is used in the model,
OBJECT_VERSION_ID is not sensibly substitutable.
This goes for why GENERIC_ID is required and not just make
OBJECT_ID concrete, but we have been there before.
it is to do with preventing inappropriate substitutability - if we made
OBJECT_ID concrete and specified it in the model in various places, you
could get archetype_ids or whatever where they cannot make sense.
Do you have a principle
that concrete classes must only inherit abstract classes? This results in
more classes in the model and you have problems with naming them. Now
GENERIC_ID has a scheme attribute which is not used in the other siblings so
that makes sense, but HIER_OBJECT_ID adds no features over the UID_BASED_ID
except being concrete.
that isn't a problem; it is a standard pattern to ensure the correct
substitutability....
- thomas