Review type of ACTIVITY.action_archetype_id

Description

Right now the type of ACTIVITY.action_archetype_id it should be better to make it ARCHETYPE_ID.

Environment

None

Activity

Show:
Thomas Beale
April 2, 2016, 12:44 PM

Hi Pablo, this was thought about a long time ago, and it was decided that since Archetype Ids are parseable, to use the String form in the data field and the standard parser on it to obtain ARCHETYPE_ID. In fact, ARCHETYPE_ID just contains a String object, with functions to obtain the elements via parsing, so I don't think it makes any difference - what you normally do is use a constructor like:

new ArchetyeId (String anId) {...}

Pablo Pazos
April 2, 2016, 3:56 PM

Hi Thomas, from the programming point of view, the model allows me to parse anything there, code bugs happen, so I might be loading an invalid format for the string. What I think ARCHETYPE_ID adds is the validation of the string. If the string is not a valid arch id, the constructor shouldn't allow to create the instance.

Using a string we lose that encapsulation. Also, from the ARCHETYPE_ID is easy to get the string back.

From the model, with the UML alone you can't tell what format that string should have, so we need the description saying "this string has this format..." etc. but on this specific case we can resolve it on the UML alone, using a class that already exists on the model.

My 2 cents

Thomas Beale
April 4, 2016, 10:00 AM

Indeed, it is the usual programming approach to validate an id e.g. with code like following from the ADL parser:

arch_specialisation: SYM_SPECIALIZE V_ARCHETYPE_ID
{
if archetype_id_parser.valid_id_reference ($2) then
parent_archetype_id := $2
else
abort_with_error (ec_SASID, Void)
end
}

See https://github.com/openEHR/adl-tools/blob/master/components/adl_compiler/src/syntax/adl/parser/adl_14_parser.y

There is the eternal tension between: store a serialised (syntax) form, and do more work on retrieval, and store an AST form which is more complex (and may be a lot bigger in XML) but do less work on retrieval. Personally I think the former is better for small, well-defined fragments, because it reduces the leaf level complexity of DB schemas, XML schemas and so on. But others may have a different view, and this should be discussed.

Thomas Beale
April 25, 2018, 4:28 PM

I think we have to reject this, or if we want it, it has to be RM Release 2.x, because it is a breaking change.

Reporter

Pablo Pazos

Labels

Components

Affects versions

Priority

Major
Configure